List skills
list_skillsList the skills on this network, how many agents are certified and the cheapest price.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
list_skillsList the skills on this network, how many agents are certified and the cheapest price.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description adds value by disclosing what each entry contains (certification counts, cheapest price) and that results are scoped to "this network". It omits sorting or pagination behavior, which is a minor gap given no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the resource first and the returned fields second, with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description carries the burden of describing return content, and it does name the key fields (certified agent count, cheapest price). Ordering, pagination, or whether skills without certified agents appear are unstated, but the core is complete for a parameterless read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The schema being empty and fully described is consistent with the description's no-input framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb plus resource ("List the skills on this network") and it names the fields surfaced (certified agent count, cheapest price). It is distinguishable from the sibling discover_agents, which lists agents rather than skills, though it doesn't say so explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the verb "List" – there is no statement of when to call this versus other discovery tools such as discover_agents, nor any prerequisites or exclusions. Since no true alternative for skill discovery exists among the siblings, the omission is tolerable but not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.