Skip to main content
Glama
event4u-app

@event4u/agent-config

Official

suggest_skill_for_task

Read-only

Match a free-form task to ranked skills by deterministic keyword scoring when you cannot ask by skill name. Returns candidates with scores, personas, and routing criteria for selection.

Instructions

Rank skills against a free-form task by deterministic keyword scoring over SKILL.md frontmatter. Use when the skill you need is absent from the host's catalogue — one measured host dropped 402 entries from its model-visible list — so asking by name is impossible and asking by task is not. Each row gives a name, score, personas and the skill's own description, its routing criteria including any clause pointing elsewhere. Choose by reading the rows, then open at most two bodies with read_skill. Read-only: no shell, no writes, no bodies.

Input Schema

NameRequiredDescriptionDefault
taskYesThe task to match skills against.
limitNoMaximum skills to return; the default is a pre-registered recall depth, not a round number.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv16.5.0
    • changedInput schema / properties / limit / default
      Previous value: -5New value: +8
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of skills to return. Defaults to 5."New value: +"Maximum skills to return; the default is a pre-registered recall depth, not a round number."
    • changedInput schema / properties / task / description
      Previous value: -"Free-form description of the task to match skills against."New value: +"The task to match skills against."
  2. Addedv14.2.0
  3. Removedv9.11.0
  4. Changed2 schema fields changedv1.0.2
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of skills to return. Defaults to 5."
    • addedInput schema / properties / task / description
      Added value: +"Free-form description of the task to find a skill for."
  5. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds the scoring mechanism, the guarantee of no shell/writes/bodies, and the exact row contents (name, score, personas, description, routing criteria including clauses pointing elsewhere). This is meaningful behavior beyond the annotation.

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?

Front-loaded with purpose, then rationale, then return shape and follow-up action. Dense but every clause carries information; slightly long sentences cost it a perfect score.

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 no output schema, the description correctly describes the returned rows and their fields, and it explains the read-only constraints and next step. Nothing needed to invoke it 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%, so both parameters are already documented, and the description adds nothing about the task or limit parameters beyond what the schema states. Baseline 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?

States a specific verb (rank), resource (skills), input (free-form task) and the mechanism (deterministic keyword scoring over SKILL.md frontmatter), which cleanly separates it from list_skills and read_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 scopes when to use it — when the needed skill is absent from the host catalogue so name-based lookup is impossible — and prescribes the follow-up flow: choose from rows, then open at most two bodies with read_skill.

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