Skip to main content
Glama
Sign In
ansible-know-mcp

ansible-know-mcp

by leogallego
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Skill

get_skill
Read-only

Retrieve a skill's SKILL.md content by name to view Ansible module or collection guidance. Provide a module FQCN or collection namespace to locate the matching skill file.

Instructions

Read a specific skill's SKILL.md content by name.

Searches ANSIBLE_KNOW_SKILLS_PATH (colon-separated) when set, otherwise the single SKILLS_DIR. First match wins.

Returns: SKILL.md content as str, or {"error": str} on failure/not found.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "skill_name": "<skill_name>"
    },
    "name": "get_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
skill_nameYesSkill name: a module FQCN (e.g. 'netbox.netbox.netbox_device') or a collection namespace (e.g. 'netbox.netbox') for the collection-level skill.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.8/5.0
Behavior4/5

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

The readOnlyHint already covers the safety profile, so the bar is low. Even so, the description adds genuinely useful behavior: the resolution order across ANSIBLE_KNOW_SKILLS_PATH (colon-separated) versus SKILLS_DIR, and the first-match-wins rule, which the schema and annotations do not express. The failure mode is also disclosed as an error object rather than an exception.

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?

Three short blocks: what it does, how it resolves the path, and what it returns. The scoping statement is front-loaded and nothing is padded. The trailing Returns line mildly overlaps the output schema but earns its place by flagging the error-object alternative.

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?

With one required parameter, full schema coverage, an output schema, and readOnlyHint set, the description only needs to explain lookup resolution and success/failure shape, and it does both. Minor gaps remain, such as case sensitivity and whether partial or ambiguous names are tolerated.

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% and the skill_name property already documents both accepted forms, the FQCN and the collection-namespace variant. The description only restates 'by name' and adds no syntax, matching, or normalization detail beyond the schema, so the baseline of 3 applies.

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 opens with a specific verb and resource: 'Read a specific skill's SKILL.md content by name.' That distinguishes it from the list-oriented and generate-oriented siblings without naming them, so an agent can tell that this is the single-item retrieval tool. The description never names a sibling explicitly, which keeps it short of a 5.

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 only implied: the 'by name' phrasing tells the agent it must already know the skill, and the lookup-path sentence explains where that name is resolved. There is no explicit when-to-use, when-not-to-use, or 'use list_skills instead if you don't know the name' guidance, which is exactly the ambiguity an agent would hit here.

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

Deploy Server

Other Tools