aiskillstore

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
Each tool has a clearly distinct purpose, from uploading skills (two modes) to searching, downloading, checking statuses, and managing reviews. No overlapping or confusing tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., upload_skill, check_draft_status, list_categories). No mixed styles or vague verbs.
Tool Count5/5
18 tools cover the full scope of a skill store: upload, search, download, review, vetting, platform/category listing, developer registration, and agent stats. Well-scoped and not excessive.
Completeness4/5
The surface covers most necessary operations for a skill store, including upload, search, download, reviews, and vetting. Minor gaps like explicit update/delete for skills are absent, but reviews support update via re-call.
Average 4/5 across 18 of 18 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It only mentions the return content (schema info) but does not address read-only nature, side effects, rate limits, or required permissions. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes redundant sections (Args/Returns) and a bilingual version. Some of the content (e.g., the Korean translation of the same information) could be considered extraneous for typical English usage. Still, it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description does not need to detail return values. However, with no annotations and minimal behavioral context, the description leaves gaps regarding safety and usage context. Given the tool's simple nature (single parameter), this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'skill_id' with no description (0% coverage). The description merely repeats the parameter name and provides a Korean translation ('스킬 ID'), adding no meaningful semantic detail beyond the schema itself. For a single parameter, the description should have clarified the expected format or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the full schema for invoking a skill, listing specific components (interface spec, input/output schemas, permissions, capability tags). This is a specific verb+resource combination, but it does not explicitly differentiate from sibling tools like 'get_skill' or 'download_skill', which may cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'get_skill' or 'download_skill'. The description only states what the tool does, not when it is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It fails to disclose whether the tool is read-only, requires authentication, or has rate limits. It mentions the returned statistics but does not state side effects or behavior beyond data retrieval. For a stats-gathering tool, this is minimal.
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?
The description is bilingual but not overly long, with clear 'Args' and 'Returns' sections. It avoids redundancy, though the initial line and Korean text could be merged. Overall, it is well-structured and each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values, but it lists them anyway, which is helpful. However, it lacks usage context and behavioral transparency. For a single-parameter tool with no annotations, it covers basic functionality but leaves gaps in when and how to use it.
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?
The description adds meaning to the single required parameter 'agent_name' by stating it must match the X-Agent-Author header. With 0% schema description coverage, this helps, but it does not provide format, validation rules, or examples. The schema itself only specifies type string, so the description provides some but not full compensation.
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 tool returns identity statistics for an agent, specifically claim success rate and counts. It distinguishes from siblings like get_agent_author_stats by focusing on claims and using the Korean text to clarify it queries drafts uploaded by the agent author. The verb 'Get' and resource 'identity stats' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_agent_author_stats or check_draft_status. The description does not mention prerequisites, context, or exclusions. The Korean phrase '공개 조회' (public inquiry) hints at accessibility but does not provide concrete usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, requires authentication, or has side effects. Being a 'get' tool implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and includes both English and Korean, but the Korean parts are somewhat redundant. The Args/Returns structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an existing output schema mentioned, the description covers purpose, parameter, and returns. However, it lacks usage guidelines and behavioral transparency, limiting completeness.
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?
With 0% schema description coverage, the description adds valuable context for the single parameter 'agent_name' by providing an example and Korean explanation, going beyond the schema's title.
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 tool's function: retrieving contribution stats for an agent author, specifying items like uploads, claims, and attribution history. It distinguishes from sibling tools like get_agent_identity_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prereq conditions or exclusions. It simply describes what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing the burden on the description. The description indicates a read-only list operation, but does not disclose any behavioral traits such as data source, caching, or side effects. Adequate for a simple list tool.
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?
The description is very concise with two sentences (English and Korean), front-loading the purpose. The inclusion of a return type adds value, though it is slightly redundant given the output schema.
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?
Given no parameters and an existing output schema, the description is reasonably complete. It specifies the resource and return type, leaving little ambiguity for a simple list tool.
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?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter meaning beyond the schema, aligning with the baseline of 3 for high coverage.
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 'List' and the resource 'supported platforms', with examples of platform names. It is specific and distinguishes itself from sibling tools, none of which list platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor when not to use it. The simplicity of the tool partially excuses this, but the dimension requires explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond being a read operation. There is no mention of rate limits, permissions, or error handling.
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?
The description is concise, with two English sentences and a brief Args/Returns section. It is well-structured but includes redundant bilingual text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an output schema, the description covers basic functionality but lacks details on error scenarios and when to use this tool among siblings.
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?
The schema has 0% description coverage for the sole parameter, but the tool description adds meaning by specifying it is the skill_id from search_skills results. This helps the agent understand the source and format.
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 it retrieves detailed info for a specific skill, listing included fields (description, platforms, version history, author, security vetting). This differentiates it from sibling tools like search_skills and get_skill_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the parameter description ('skill_id from search_skills'), but there is no explicit guidance on when to use this tool versus alternatives or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description only mentions the return format ('category list string'). It does not disclose any behavioral details such as ordering, caching, authentication requirements, or whether the list can be empty.
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?
The description is short and front-loaded with the key action. However, the Korean translation is redundant for an English-capable AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters, the description covers the basics. However, it misses contextual details like prerequisites or behavioral traits (e.g., authentication, caching).
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?
The input schema has no parameters (100% coverage), so the description adds minimal value beyond saying it returns a list. An output schema exists, so the return type is already defined.
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 'List all available skill categories' with a specific verb and resource. It distinguishes itself from sibling tools, none of which list categories.
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?
The description says 'List all available skill categories' which implies it should be used when a complete list of categories is needed. No sibling offers similar functionality, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full behavioral burden. Mentions ownership restriction and return is a status message, but does not explicitly state this is a read-only operation or describe side effects, rate limits, or failure modes.
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?
Description is short and front-loaded with purpose. Bilingual content adds length but remains efficient. Every sentence provides needed information; no fluff. Could be slightly more concise by dropping one language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema available, description does not need full return details, but it only mentions '검수 상태 메시지' vaguely. It covers core usage but lacks mention of output schema or potential errors. For a simple 2-param tool, it is acceptable but incomplete.
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?
Explains both parameters beyond schema: version_id as coming from upload_skill result (or vetting_job_id) and api_key as developer API key. This adds meaningful context beyond the basic schema titles. However, format details are lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check the security vetting status of an uploaded skill version' with verb+resource. However, it does not distinguish from sibling tools like check_draft_status or get_vetting_result, missing explicit differentiation.
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?
Specifies prerequisites: version_id from upload_skill result and api_key. Mentions only skill owner can query. Provides clear context for when to use but omits alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as side effects, authentication needs, or error handling. It only states the basic function and return type.
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?
The description is extremely concise with a clear purpose statement in two languages and a structured Args/Returns section. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description covers basic parameter and return semantics but omits default values and usage context, which could improve completeness.
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?
With 0% schema description coverage, the description adds significant meaning by listing parameter names, brief explanations, and enumerated values for platform, compensated adequately.
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 it retrieves step-by-step installation instructions for a skill on a specific platform, distinguishing it from sibling tools like get_skill or download_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for installation instructions, but does not explicitly state when to use or not use this tool, nor does it mention alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 platform conversion and default save behavior but does not mention whether the operation is read-only, authentication needs, or error handling.
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?
The description is concise with two paragraphs, a clear Args list, and Returns section. No unnecessary sentences, well-structured for quick parsing.
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?
Given the existence of an output schema, the description adequately covers return values (file path or error). For a simple tool with 3 params, it is nearly complete, though could mention if overwriting occurs.
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 0%, but the description adds value by explaining the platform options (enum list), default behaviors (original .skill download, temporary directory), and the purpose of each parameter beyond their titles.
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 'Download a skill package' and specifies the platform conversion feature. It distinguishes from siblings like get_skill (which likely retrieves metadata) by focusing on file download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to specify platform but does not provide explicit guidance on when to use download vs other tools like get_skill. No alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions email verification and delayed API key issuance, but lacks details on failure modes (e.g., duplicate username) or side effects. The 'Returns' section is somewhat vague.
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?
The description is structured with separate sections for args and returns, and includes bilingual text. It is clear but slightly verbose; could be more concise but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a registration tool with 2 parameters and an output schema, the description covers the core flow but omits important details like validation rules, duplicate handling, and format specifics. An output schema exists, reducing some burden, but more depth would improve completeness.
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?
Input schema has no descriptions (0% coverage). The description adds meaning to both parameters: username constraints (English/numbers, 3+ chars, unique) and email purpose (required, verification link sent). This compensates for the schema gap.
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 action ('Register a developer account') and the resource ('AI Skill Store'), distinguishing it from sibling tools like upload_skill or get_skill. The bilingual text reinforces the purpose.
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?
The description explains the email verification step and that the API key is not immediate, but does not explicitly state when to use this tool vs alternatives. However, given the tool name and sibling list, usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It indicates the tool returns a status summary (claimed, expired, etc.) and implies it is a read-only query, but does not disclose idempotency, rate limits, or token validity beyond the initial upload.
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?
The description is concise, starting with a clear purpose in English and Korean, followed by structured usage points and parameter/return details. Every sentence adds value with 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?
With only one parameter, clear purpose, and an output schema that exists, the description provides sufficient context. It lists possible return statuses and the conditions for calling the tool, making it complete for its complexity.
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 0%, but the description explains that claim_token comes from the upload_skill_draft response, adding crucial context. However, it does not specify the token's format, length, or any constraints, leaving some gaps.
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 tool checks the status of a draft skill upload using a claim_token. It lists three specific use cases (verifying if a claim_url was clicked, agent-level verify email processed, or draft claimed/expired), distinguishing it from siblings like check_vetting_status which checks different tokens.
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?
The description explicitly provides a 'when to use' section with three bullet points, defining clear contexts for invoking this tool. While it does not mention when not to use it or alternative tools, the guidance is strong enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses mutation behavior (creates/updates), idempotency via re-call, ownership restrictions, and rate limits. It does not detail error handling or data persistence, but covers key behavioral traits well.
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?
The description is well-structured with clear sections (purpose, policies, Args, Returns) and is concise, including both English and Korean. It wastes no words, though the bilingual text slightly increases length without adding new 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?
Despite 0% schema coverage and moderate complexity (4 params, 2 required, output schema exists), the description provides thorough parameter details and behavioral rules. It mentions return type ('결과 메시지') but delays detailed output to the schema. With output schema present, this is sufficient.
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?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly: defines skill_id, rating (1-5 integer), comment (optional, max 2000 chars), and api_key (required). This adds meaning far beyond the bare schema, providing complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Post a review and rating for a skill.' The verb 'post' and resource 'review and rating' are unambiguous. However, it does not explicitly distinguish it from sibling tools, though the unique name and purpose suffice.
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?
The description provides explicit policies: one review per user per skill (with re-call acting as update), cannot review own skill, and a rate limit of 10/hour/IP. This informs the agent when to use the tool and constraints. It lacks explicit when-not-to-use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details the return fields (name, description, downloads, rating, trust level) and explains sorting behavior. It does not disclose side effects or auth requirements, but it sufficiently describes the tool's behavior for a search operation.
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?
The description is well-structured with clear sections and bullet points, but it is somewhat lengthy due to bilingual content. Each sentence serves a purpose, though conciseness could be improved by removing redundant phrasing.
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?
The description covers all 7 parameters with usage details, explains return format, and clarifies behavior differences (agent search vs. general search). Given the output schema is a simple string, the description is complete and leaves no major gaps.
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?
Since schema description coverage is 0%, the description fully compensates by detailing each parameter's meaning, examples, constraints (e.g., default values, max limit), and conditional applicability (e.g., category/sort only without agent search). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search skills on AI Skill Store' and explains the search behavior with specific terms like 'capability' and 'platform'. However, it does not explicitly differentiate from sibling tools like get_skill, but the context implies this is a list/search function.
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?
The description provides explicit guidance on when to use 'capability' or 'platform' for agent-optimized search and notes that 'category' and 'sort' only apply when not using that mode. It does not, however, direct when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the check is based on python/packages and platform compatibility, and returns a summary with compatibility status, missing packages, and install recommendations. It implicitly indicates a read-only operation.
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?
The description is concise, mixing English and Korean for clarity, and includes a structured Args section. A slight redundancy exists (e.g., 'before downloading' repeated) but overall efficient.
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 the tool's moderate complexity, the description covers purpose, parameters, behavior, and return value (output schema exists, so return explanation is sufficient). It is complete for an agent to understand and invoke the tool.
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?
With 0% schema description coverage, the description fully compensates by listing each parameter with its purpose and format (e.g., python_version as '3.11.2', installed_packages as a dict). This adds meaning beyond the schema, enabling correct use.
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 tool checks compatibility of a skill with a platform before downloading. This distinguishes it from sibling tools like check_draft_status or download_skill, as it is a pre-download validation.
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?
The description explicitly says 'before downloading' and includes Korean text reinforcing the timing. It does not state when not to use, but the context of siblings makes the usage clear and there are no direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers what the tool does (returns a ranked summary of demanded skills), parameter constraints, and output format, with 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?
Extremely concise with clear language, Korean translation, and structured Args/Returns sections; every sentence adds value.
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?
Description adequately covers behavior and return format, but could mention that the output is a string summary (not structured data) given multiple siblings; still sufficient for a list retrieval.
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?
Description adds essential details to input schema parameters: min/max for days and limit, and valid enum values for type, compensating for 0% schema coverage.
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?
Description explicitly states it retrieves a list of most-wanted skills that haven't been built yet, clearly distinguishing it from sibling tools like search_skills or download_skill.
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?
Description indicates the tool is meant for agents to identify skills to build to meet community demand, but does not explicitly mention when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication options, polling behavior (is_done flag), and return contents (vetting_status, findings). Lacks details on error cases or rate limits, but overall good for no annotations.
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?
Structured with clear sections (purpose, auth, usage, args, returns). Slightly longer than necessary but front-loaded with key info.
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 input, authentication, polling behavior, and output structure. Adequate given output schema exists and sibling complexity. No critical missing info.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's source, purpose, and mutual exclusivity (api_key vs claim_token). Adds significant value beyond the bare 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 clearly states that the tool gets the detailed security vetting report for a skill, with polling via job_id and optional authentication methods. It distinguishes from sibling tools like check_vetting_status by specifying thorough retrieval.
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?
Explicit guidance on when to use this tool (post-upload polling) and alternatives (claim_token for agents without API keys). Explains polling logic and the official recommended path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses API key requirement, two modes of operation, and return values (version_id, vetting_job_id, poll_url). Could be more explicit about side effects (e.g., submission to vetting) but is adequate.
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?
Well-structured with sections for modes and bullet points. Front-loaded with purpose. Slightly lengthy due to detail, but efficient given two modes.
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 necessary aspects: purpose, prerequisites, mode selection, parameter details, return values, and alternative tool. Complete for an agent to invoke correctly.
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?
Schema has 0% description coverage, but description thoroughly explains each parameter: api_key (required), file_path (mode B), skill_md, files, requirements, author_agent (mode A). Examples and types are given, compensating fully.
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?
Description clearly states 'Upload a skill package to AI Skill Store. Requires an API key.' It differentiates two usage modes and explicitly distinguishes sibling tool 'upload_skill_draft' as alternative when no API key.
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?
Provides explicit guidance: when to use each mode (JSON content vs file path), references upload_skill_draft as alternative without API key, and warns not to use both modes together.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: only approved drafts accepted, sandbox tier, claim_status='draft', same agent_author drafts batch-claimable via email, and mandatory actions like not auto-claiming. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately long but well-structured with sections (Policy, Mandatory Actions, Args, Returns). Front-loaded with purpose. Bilingual content (Korean/English) adds slight redundancy but overall efficient for the complexity.
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 7 parameters, 2 required, no annotations, and an output schema (mentioned but not detailed), the description covers all necessary aspects: input, behavior, return hints (includes claim_url, human_action_required), and mandatory actions. Complete for autonomous agent usage.
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?
Since schema description coverage is 0%, the description adds extensive meaning for all 7 parameters in the 'Args' section, including usage rules for contact_email (e.g., do not guess, leave empty if unknown) and agent_secret (store and reuse).
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 'Upload a skill without an API key (zero-friction)' and 'Perfect for agents contributing skills autonomously'. It specifies the action (upload), resource (skill), and mode (draft). Distinguishes from siblings like 'upload_skill' by emphasizing no API key needed.
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 explicit mandatory agent actions and policy details (e.g., save agent_secret, display claim_url, wait for user input). Implicitly differentiates from 'upload_skill' by mentioning zero-friction, but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![aiskillstore MCP server](https://glama.ai/mcp/servers/garasegae/aiskillstore/badges/card.svg)](https://glama.ai/mcp/servers/garasegae/aiskillstore)

Score Badge

Copy to your README.md:

[![aiskillstore MCP server](https://glama.ai/mcp/servers/garasegae/aiskillstore/badges/score.svg)](https://glama.ai/mcp/servers/garasegae/aiskillstore)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/garasegae/aiskillstore'

If you have feedback or need assistance with the MCP directory API, please join our Discord server