Skip to main content
Glama

Dom Kozak: pDOOH and Built for MENA

List Dom Kozak's pDOOH lessons

list_lessons
Read-only

Released pDOOH 101 and 201 lessons, in order, with series, episode, title, hook, airDate and URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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 real context beyond that: results are ordered ('in order') and each entry carries series, episode, title, hook, airDate and URL. It does not mention pagination or whether the set is exhaustive.

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?

One short sentence with no filler, and the field list is front-loaded. It is slightly under-structured as a fragment with no leading verb, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 usefully compensates by naming the returned fields, and the read-only annotation covers the safety profile. The gap is the absence of any differentiation from the sibling list_episodes, leaving the agent unable to tell the two similarly named listing tools apart.

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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly implies a no-argument, full-enumeration call.

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

Purpose3/5

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

The description is a noun-phrase fragment ('Released pDOOH 101 and 201 lessons...') that enumerates contents rather than stating a verb+resource action like 'List lessons'. The title supplies the verb, but the description itself reads as a content spec rather than a purpose statement. It is still specific enough that an agent can guess this returns a curated lesson set, but the relation to the sibling list_episodes is not addressed.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all, no condition distinguishing this from list_episodes or search_podcast. The phrase 'in order' hints at an ordered enumeration, but nothing tells the agent when this tool is preferable to a sibling.

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.

Resources