Server Quality Checklist

Tool Scores

• search_skillselionA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of disclosing behavior. It mentions ranking by community signal but does not explicitly state that the tool is read-only or non-destructive. While search is inherently safe, the description could be more transparent about side effects or permissions.

  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 purpose and key features. Every sentence adds distinct value: first sentence explains what is searched and ranking, second gives usage examples and links to sibling tool. No wasted words.

  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 3 parameters, no output schema, and no annotations, the description is sufficiently complete. It covers the tool's purpose, usage context, and integration with a sibling tool. The lack of return value description is acceptable as no output schema exists, but additional behavioral details 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?

  Schema coverage is 100% with descriptions for all three parameters. The description adds value by explaining that 'query' can be a tool, framework, task, or keyword, and that 'type' restricts to one listing. It also provides context on ranking, which enhances understanding of results, though it doesn't directly enrich parameter definitions.

  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 verb 'Search' and the resource 'Skillselion directory' of skills, MCPs, and marketplaces. It differentiates from 'load_skill' by specifying that browsing is for searching, not using. However, it does not explicitly distinguish from 'synthesize_skills' or 'top_skillselion'.

  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 usage guidance: 'Use to browse trusted skills/MCPs/marketplaces for the task at hand' and when to call 'load_skill' instead. Example queries are given. It does not mention alternatives for other sibling tools, but the core use case is covered.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• top_skillselionA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided; description reveals ranking criteria (installs, stars) but omits details like data freshness, pagination, or side effects. Adequate for a read-only 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose, followed by ranking specifics. No superfluous words; each 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 simple listing tool with 2 params and no output schema, the description provides key behavior and ranking details. Could hint at default limit or result structure, but sufficient for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. Description adds value by explaining how the 'type' parameter affects ranking (installs vs stars), which is beyond the schema's enum listing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool lists top entries on Skillselion leaderboard, with optional type filtering. Distinguishes from siblings like load_skill, search_skillselion, and synthesize_skills by focusing on leaderboard rankings.

  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?

  Implies usage for fetching top entries but does not explicitly state when to use vs alternatives. No when-not or exclusion guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• synthesize_skillsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so the description carries full burden. It discloses that the tool pulls top matching skills, merges them, deduplicates, returns a provenance-tagged digest, and materializes source skills on disk. This is transparent, though it could mention how 'top matching' is determined.

  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 efficient and front-loaded, starting with the core action and then providing usage context, alternatives, parameter guidance, and output summary. It is succinct but could be slightly more streamlined.

  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 output schema, the description adequately explains the return format (deduped, provenance-tagged digest plus materialized files) and input parameters. For a tool with two simple required parameters and no nested objects, this is fairly complete. It does not detail the selection criteria for 'top matching,' but that is acceptable.

  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 100%, so baseline is 3. The description adds minor clarification by explaining how to use each parameter (e.g., 'pass your task as query and your stack + constraints as context'), which is helpful but not essential beyond the 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 the tool's purpose: pulling the best rules from top community skills and merging them into a cross-source playbook. It specifies the action (synthesize/merge), resource (skills), and scope (broad tasks), and distinguishes from sibling load_skill.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly describes when to use (broad 'how should I approach X' tasks spanning multiple skills) and when not to (single skill -> use load_skill). Also clarifies required parameters and their roles.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_skillA
  4.5/5.0
  Behavior4/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 describes the return (best match + next-best candidates), materialization to a temp folder, and warns to verify. It also explains the purpose of context. Could mention if any mutations occur, but likely not needed.

  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 somewhat long but well-structured: first sentence gives purpose, then usage guidelines, then parameter details, then warning. All sentences add value. Could trim slightly but no waste.

  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 3 parameters, no output schema, and no annotations, the description covers the tool's behavior thoroughly: explains what the tool does, how context is used, what is returned, and a verification warning. No gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond schema: context 'ranks candidates, fits them to your repo, flags dependency mismatches'. Also provides example values for parameters.

  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 purpose: 'Load a community-vetted skill into your context on demand'. It uses a specific verb ('load') and resource ('skill'), and distinguishes from siblings by mentioning 'synthesize_skills' for broad tasks.

  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 on when to use ('when a task is in a domain a skill likely covers...') and when not ('For broad... tasks that span several skills, use synthesize_skills instead'). Also specifies the context parameter's role.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.