Skip to main content
Glama
Sign In
kadal-store

kadal-store

Official
by kadalcc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Report a problem

report_problem

File a private note to Kadal about a product issue, question, or idea, including the file name and page or timestamp so it can be reviewed and answered.

Instructions

Tell Kadal about a product the person has: a mistake (a typo, a wrong date, a missing page, a broken file), a question, or an idea. Say where with fileName and page (PDFs, from 1) or timeSeconds (audio and video). The note is private to the person and Kadal, and its replies show in list_my_notes. Report only what you checked, in plain words, once per problem, and tell the person you filed it.

Input Schema

NameRequiredDescriptionDefault
bodyYesWhat is wrong and where, in plain words.
kindYes
pageNoThe PDF page, counting from 1.
slugYes
fileNameNoThe file the problem is in, as list_library names it.
timeSecondsNoSeconds into the audio or video.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (which confirm it is a writable operation), the description offers critical workflow context by stating that the notes are 'private to the person and Kadal' and how replies are handled. This provides necessary meta-information regarding the note's visibility.

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?

While the description is moderately sized, it is highly dense and functional. It front-loads the purpose and flows logically into behavioral constraints, ensuring that almost every sentence provides necessary instructional value.

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?

The tool handles complexity by managing three different issue kinds and multiple media formats. The description comprehensively covers the boundaries of reporting (what to check, how to report it) and the privacy implications of the resulting note.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Given that schema coverage is moderate (67%), the description is excellent at providing semantic guidance for the media location parameters. It explicitly links `page` to PDFs and `timeSeconds` to audio/video, allowing the AI to logically group and select the correct parameter based on the file type.

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?

The description clearly defines the action (reporting) and the specific types of issues (mistake, question, or idea) it addresses regarding a product. By focusing on these specific problem types, it strongly differentiates itself from general library searching or listing siblings.

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?

The description provides explicit behavioral rules for usage, such as reporting 'only what you checked' and filing it 'once per problem.' This minimizes ambiguity and sets clear constraints on how and when the tool should be invoked.

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