Skip to main content
Glama

Dactic

How my Dactic skills are used

get_skill_usage
Read-onlyIdempotent

How often your Dactic skills were listed and loaded by AI clients (ChatGPT, Claude…) over the last 7, 30 or 90 days, how many live agents use each, and a suggestion (promote, keep, review or trim) with its basis. Suggestions are advice and never change anything. data_since is when counting started; there is no earlier history. scope=org is for org admins.

Input Schema

NameRequiredDescriptionDefault
limitNo
scopeNo
skill_slugNo
next_cursorNo
window_daysNo

Output Schema

NameRequiredDescriptionDefault
skillsYes
statusYes
messageNo
has_moreNo
data_sinceNo
next_cursorNo
window_daysYes
channels_without_dataNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, non-destructive and idempotent, yet the description adds real value: suggestions are advisory and never change anything, and history before data_since simply does not exist. That pre-empts the two most likely agent misreads (that it mutates state, or that it can look further back).

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?

Three sentences, front-loaded with what is returned, then the read-only caveat, then the field-specific notes. No filler, though the opening sentence is dense enough that the scope and window details could be split for easier scanning.

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?

An output schema exists, so return shape need not be spelled out, and the description still usefully covers the data_since caveat and the advisory nature of suggestions. The only real gap is pagination behavior for limit/next_cursor, which matters for a list-style tool.

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 0% across five parameters, and the description compensates only partially: it explains the 7/30/90-day window and that scope=org requires admin rights. limit, next_cursor and skill_slug are left entirely unexplained in both schema and description.

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 names the specific resource (Dactic skill usage) and the exact measures returned: listing/load counts by AI clients, live agents per skill, and a promote/keep/review/trim suggestion. It is clear what the tool reports; it just never names its nearest sibling (get_usage) to sharpen the boundary.

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?

Implicit guidance exists: choose a 7/30/90-day window, and scope=org is restricted to org admins. There is no statement of when to reach for this tool instead of get_usage, get_skill, or list_skills, so an agent must infer the choice.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.