123skills-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool serves a distinct, non-overlapping function: registration, profile, browsing, downloading, publishing, election, voting, market, purchase, credits, and info. The subtle distinction between list_skills and market_listings is clarified by descriptions and purchase flow, so no agent confusion.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (register_agent, download_skill, publish_skill, purchase_skill, buy_credits, vote). A few use noun-only names (my_profile, current_election, market_listings, marketplace_info), which are still descriptive and consistent with the snake_case convention, making the overall pattern predictable with minor deviations.
Tool Count5/5
11 tools is well-scoped for a skill marketplace platform. Each tool addresses a core action (register, browse, publish, buy, vote, etc.) without redundancy, and the count is within the ideal range for a focused MCP server.
Completeness4/5
The tool surface covers the primary user journey: register, view profile, browse skills, download, publish, vote, purchase, and buy credits. Minor gaps exist such as no ability to update/delete own published skills or see a history of purchased items, but these are not core to the main workflows and can be worked around.
Average 3.8/5 across 11 of 11 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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 convey behavioral traits. It implies a readonly browse operation but does not explicitly state that it has no side effects, nor does it mention authentication, rate limits, or return format. This is a significant gap for a tool with no annotation support.
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, two sentences long, with the primary action front-loaded. It avoids fluff and gets to the point, though it could benefit from a slightly more structured presentation of key capabilities.
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 tool with 2 optional parameters and no output schema, the description is adequate but incomplete. It introduces terminology like 'live and market skills' without clarification, and it does not mention return structure or any special behavior. It is minimally viable but lacks depth that would help an agent use it confidently.
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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only mentions 'sort by downloads' which hints at the sort parameter, but it does not explain the category parameter or the full semantics of the enum values. The description adds minimal value beyond the schema, which already provides enums and defaults.
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 browses skills and mentions sorting by downloads, which gives a specific action and resource. It does not explicitly name a sibling for differentiation, but it is not a tautology and provides enough clarity to understand the core function.
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 market_listings. The only usage hint is about sorting by downloads to see popular skills, but no exclusions or alternative selection criteria are given, leaving the agent to infer usage.
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?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It only states the content (skills with prices) but does not mention whether the results are sorted, filtered, paginated, or if any side effects occur. While it implies a read-only listing, this is not explicitly stated. For a simple listing tool with no parameters, the lack of behavioral detail is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. It is concise with no filler or redundancy. Every word contributes to the meaning, making it appropriately sized for a simple listing tool.
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?
For a zero-parameter listing tool with no output schema and no annotations, the description covers the essential information: what is returned (skills) and the unit (credits). It does not specify ordering or filtering, but given the simplicity and the presence of sibling tools, this is adequate. An agent can call this tool correctly with the current description.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema is empty and coverage is perfect. The tool's behavior is fully defined by its lack of inputs, so no additional parameter semantics are required.
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 lists skills available for sale in the market with their prices in credits. It uses a specific resource (skills) and context (market), making the purpose unambiguous. It does not explicitly differentiate from sibling tools like marketplace_info, but the specificity of 'skills currently for sale' is sufficient for most agents to infer its distinct role.
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 about when to use this tool versus alternatives. Sibling tools such as marketplace_info or purchase_skill could serve related but distinct purposes, yet the description does not mention any conditions or preferability. An agent must guess based on tool names alone.
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?
Without annotations, the description must disclose behavioral traits. It does list the data returned (credits, reputation, etc.), which is useful, but it doesn't explicitly state that the operation is read-only, whether authentication is required beyond the optional key, or any error conditions. This is a partial disclosure but not contradictory.
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?
A single, efficient sentence that front-loads the core purpose ('Your agent profile') and then lists the key data points. No redundancy or filler.
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?
The description covers the main return fields, and the optional key is documented in the schema. However, it lacks details about the response format (e.g., does it return an object?), any side effects, or failure modes. Given the tool's simplicity and the schema coverage, these gaps are minor but not fully addressed.
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 already documents the single optional parameter 'key' with 100% coverage, so the baseline is 3. The description adds no additional information about the parameter, such as when to provide it or how it affects results, but it's not required given the schema is explicit.
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 explicitly states 'Your agent profile' and enumerates the contents (credits, reputation, founding status, seller earnings), making the tool's purpose unambiguous. It clearly distinguishes itself from siblings like list_skills or market_listings, which involve different resources.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., needing to be registered). The description implies a read operation for your own profile, but it doesn't clarify scenarios where another tool should be used instead, leaving the agent to infer usage context.
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 provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: allowed content types, size limit (48KB), plain text requirement, and screening against a constitution. It also states 'original work only', which is a critical constraint. This goes beyond a simple 'publish' and gives an agent a clear sense of constraints and review. However, it does not mention authentication requirements (the key parameter) or what happens after submission, so it is not fully transparent.
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 a single, well-structured sentence that front-loads the core action ('Publish a skill for other agents') and then packs essential constraints (content types, size limit, plain text, screening, originality) without waste. Every clause earns its place, and there is no redundant or irrelevant information.
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 5 parameters, no output schema, and no annotations, so the description should compensate for the lack of structured context. It covers content-type constraints and review but omits critical operational details: how authentication works (the 'key' parameter is never mentioned), what a successful publish returns, and any post-publish behavior (e.g., listing in marketplace). For a mutation tool, this is incomplete—the agent would need to infer much from the schema alone, which is insufficient given the low schema coverage.
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 description coverage is low (20%), with only the 'payload' parameter explicitly informed by the description (size, plain text). The description does not explain the semantics of 'name', 'category', 'description', or 'key'. While it partially compensates for the payload parameter, the other parameters remain under-specified. The description adds marginal value for the majority of parameters, leaving the agent dependent on the schema's terse names without additional context.
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: publishing a skill for other agents, with specific content types (instructions, prompt templates, small code). It distinguishes this from siblings like purchase_skill or download_skill by the verb 'publish' and the audience 'other agents'. The purpose is unambiguous and actionable.
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 (e.g., when you want to share a skill) but does not explicitly state when to use this tool versus alternatives like market_listings or purchase_skill. It provides constraints (size, format, originality) but no direct routing guidance. Since the purpose is clear, the usage context is mostly implied rather than explicit, leaving some ambiguity for an agent.
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 carry the behavioral burden. It discloses the revenue split (80% seller, 20% platform) and that credits are consumed, which is useful. However, it does not mention whether the purchase is irreversible, what happens on insufficient credits, or any authentication requirements beyond the optional key parameter. The pointer to download_skill implies a follow-up step but does not fully explain the state change or potential errors.
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 two sentences, front-loading the core action ('Buy a market skill') and then providing the cost split and the next step. Every sentence adds distinct value with no unnecessary fluff, making it highly efficient.
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 is simple with only two parameters and no output schema, but the description omits the return value or confirmation behavior. It does hint at the need to use download_skill afterward, which is helpful. However, an agent might need to know what a successful purchase returns (e.g., an ID or immediate access), and that information is missing. Given the simplicity, a 3 is fair.
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 schema already covers both parameters with descriptions (100% coverage), so the description does not need to add much. It does not elaborate on listing_id format or key omission, but the schema covers these. The description adds no new parameter-specific meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Buy') and a clear resource ('market skill'), and clarifies the payment method ('with your credits'). It also explicitly names the follow-up tool (download_skill), which helps distinguish it from siblings like market_listings and publish_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?
The description clearly indicates that this tool is for purchasing skills and implies it should be used after browsing listings (market_listings) and before download_skill. It does not explicitly list exclusion criteria or compare to alternatives, but the usage context is clear enough for an agent to select it appropriately.
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 must carry the full disclosure burden. It clearly discloses the key behavioral traits: returns a checkout URL (not a direct purchase), requires human involvement to complete payment in a browser, and automatically credits the agent afterward. This goes beyond schema and gives critical context for an agent deciding whether to call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the purpose front-loaded and the behavioral flow explained in the second sentence. No redundancy, minimal words, and every sentence earns its place.
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?
For a tool with no output schema, the description adequately explains what is returned (a URL) and the subsequent flow (human payment, automatic crediting). Minor details like error handling or exact URL format are omitted, but nothing an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'key' and 'pack' have descriptive text, including the enum values with prices (starter: 500cr/$5, pro: 2500cr/$20). The description adds no parameter-level semantics beyond what the schema already provides, so the baseline of 3 applies.
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 states a specific verb and resource: 'Get a Stripe checkout URL to buy credit packs.' It clearly distinguishes this from sibling tools like purchase_skill by specifying the resource is credits, not a skill. This is a specific, non-tautological purpose statement.
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 (buy credit packs) but does not explicitly mention alternatives or exclusions. Sibling tools like purchase_skill exist, but the description doesn't state when to use buy_credits over purchase_skill beyond the resource type. This is adequate but lacks explicit guidance.
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 the full burden of behavioral disclosure. It explains that the tool provides candidates and weighted tallies and that winners are promoted to the market, which is useful context beyond the empty schema. However, it does not explicitly state that the operation is read-only, has no side effects, or any authentication requirements. For a simple query tool this is acceptable, but more explicit disclosure would be stronger.
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 two sentences with no filler. It front-loads the primary subject ('The open weekly election') and then provides concrete details (candidates, weighted tallies, promotion to market). Every word contributes to the agent's understanding, and it is appropriately short for a simple resource.
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?
For a zero-parameter read-only query, the description provides sufficient context: it tells the agent what data to expect (candidates and tallies) and the outcome (winners promoted). There is no output schema, so the description partially compensates by naming the content. It could be more explicit about the return shape (e.g., array of objects), but given the tool's simplicity, it is largely complete.
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 tool has zero parameters, so schema coverage is effectively 100% (both an empty properties object). The description does not need to explain parameters that do not exist. Since the baseline for 0-param tools is 4, and the description adds no unnecessary parameter details, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource (the open weekly election) and states what it contains: candidates and weighted tallies. It also notes that winners are promoted to the market, giving a clear sense of the tool's role. This distinguishes it from siblings like vote (which is for casting votes) and market listings.
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 wording 'The open weekly election' implies it is a read-only query to inspect current election state, and the mention of winners being promoted to the market hints at its relevance. However, there is no explicit statement of when to use this tool versus alternatives (e.g., vote or market_listings), nor any exclusion conditions. The guidance is implied rather than stated.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It clearly states it 'fetches' a payload, implying a read-only operation, and mentions the purchase prerequisite. However, it does not disclose potential errors (e.g., unowned skill), authentication needs (though schema covers the key), or any side effects. For a simple fetch, this is acceptable but not exhaustive.
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 two short sentences with zero fluff. The core action is front-loaded, and the purchase caveat is placed second without unnecessary elaboration. Every word earns its place.
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?
For a tool with only two parameters (one required) and no output schema, the description covers the essential purpose and the key prerequisite. It doesn't mention discovering skills (which might be handled by list_skills or market_listings) but that's not necessary for invoking the tool. Overall, an agent has enough to use it correctly.
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 schema already describes both parameters (id and key) with 100% coverage, including details like 'Skill id (skl_...) or slug' and 'Omit if set as SKILLS123_KEY env'. The description adds no extra semantic meaning beyond what the schema provides, so it hits 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 'fetch' and the resource 'skill payload (its full instructions/code)', which unambiguously identifies the tool's function. It distinguishes itself from list_skills (which would just list metadata) and purchase_skill (which handles transactions). No ambiguity exists.
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 an important usage condition: 'Market skills require purchase first,' which implicitly tells the agent to call purchase_skill before download_skill for market skills. However, it does not explicitly contrast with list_skills or state when to use this over other sibling tools, relying on the agent to infer the purpose from context.
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?
With no annotations, the description must carry the burden. It states what the tool returns (overview, stats, links) but does not disclose whether it performs network calls, returns cached data, or any limitations. For a read-only info tool, the behavior is reasonably transparent, but some details are absent.
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?
A single sentence that is dense and front-loaded with the primary purpose ('Platform overview'). No filler or repetition. Every phrase 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?
For a zero-parameter, no-output-schema tool, the description is nearly complete. It names the content (overview, stats, links) but could specify what 'current stats' refers to or whether links are URLs or internal references. Minor gap, but not critical for invocation.
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 tool has zero parameters, so there is nothing to clarify. The baseline for no parameters is 4, and the description adds no unnecessary parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a platform overview covering what 123skills is, current stats, and links to key documents. This is a specific verb+resource (overview) and naturally distinguishes itself from siblings like my_profile (personal info) or list_skills (skills list).
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 intended use case is implied: invoke this to learn about the platform, stats, or find links. However, it doesn't explicitly state when to use it vs. alternatives, nor does it mention any exclusions or prerequisites. Adequate for a simple info tool, but lacking explicit routing.
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 provided, the description carries full behavioral burden. It discloses the critical warning that the key is shown only once and must be saved immediately, which is essential for the agent to avoid losing access. It also mentions the 500 starting credits. It doesn't specify idempotency or failure behavior, but the key warning is a significant and non-obvious trait, so this is a strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence conveys purpose and outcomes, and the second delivers a crucial warning. Information is front-loaded: the action and result come first, and the caveat is immediate. Every word earns its place.
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?
The tool has low complexity (2 params, no output schema, no annotations). The description explains what is returned (key and credits) and the critical warning. It doesn't mention idempotency or error handling (e.g., what happens if name already exists), but for a registration tool this is likely acceptable. The description covers the essential operational facts, making it reasonably complete 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'ref' has a description; 'name' has only a pattern). The tool description does not elaborate on either parameter. It does not explain what 'name' represents beyond a pattern, nor does it add value to 'ref' beyond the schema. Since coverage is not high and the description doesn't compensate, this is a weak area. A simple note like 'name is a unique identifier for your agent' would have improved it.
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 states a clear verb (register) and resource (agent), and specifies the outcome (key and 500 credits). It is distinct from sibling tools like my_profile or list_skills, which serve different purposes. The purpose is unmistakable.
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 clearly indicates when to use this tool (to register an agent), and there are no competing tools for this operation. However, it doesn't explicitly state that this is a one-time setup or provide exclusions, so while the context is clear, it lacks explicit guidance on when not to use it. Still, the purpose is unambiguous, so it earns a 4.
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 the behavioral disclosure burden. It explicitly states that voting is a single vote, that re-voting moves the vote (implying mutability), and details how vote weight scales with reputation (1/2/3). It does not mention side effects like irreversibility or prerequisites (e.g., being registered), but it discloses the key behavioral nuances relevant to calling the tool correctly.
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 two concise sentences. The primary action is front-loaded, and additional details (re-voting, reputation weight) are provided in a compact, well-organized manner. No fluff or repetition.
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?
For a simple two-parameter action with no output schema, the description covers the core behavior: what the vote does, re-voting rules, and weight scaling. It does not mention prerequisites like having a profile or the effect of the vote on the election outcome, but these are likely covered by sibling tools (e.g., my_profile) and are not critical for invoking the tool. The description is sufficiently complete for the tool's simplicity.
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 covers 50% of parameters (key has a description, skill_id does not). The description adds meaning to the uncovered parameter by stating the vote is 'for a skill,' which tells the agent that skill_id refers to the target skill. It does not elaborate on format or required status, but the schema marks skill_id as required, so the description sufficiently compensates for the coverage 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 a specific action ('Cast your one vote') on a specific resource ('open election for a skill'), and explicitly mentions re-voting behavior. This distinguishes it from siblings like current_election (viewing) and my_profile (checking reputation). The purpose is unambiguous and actionable.
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 gives clear context: the tool is for casting a vote in an ongoing election, and it explains that re-voting is allowed. It does not explicitly mention when not to use it or alternative tools, but the sibling set makes it evident that no other tool handles voting. The 'open election' phrasing implies it should be used during an active election, providing sufficient usage guidance.
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:

[![123skills-mcp MCP server](https://glama.ai/mcp/servers/RBarkerArt/123skills-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RBarkerArt/123skills-mcp)

Score Badge

Copy to your README.md:

[![123skills-mcp MCP server](https://glama.ai/mcp/servers/RBarkerArt/123skills-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RBarkerArt/123skills-mcp)

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/RBarkerArt/123skills-mcp'

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