Skip to main content
Glama

summarize_tajwid

Read-onlyIdempotent

Get per-rule Tajwid candidate counts for a surah or ayah range, with paged per-ayah breakdowns, to review rule distribution before annotation.

Instructions

Per-rule candidate counts for a surah or an ayah range, with per-ayah counts (paged).

Input Schema

NameRequiredDescriptionDefault
limitNo
surahYes
offsetNo
end_ayahNo
familiesNo
rule_idsNo
start_ayahNo
reading_contextYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — that results are paged and broken down per-ayah as well as per-rule — but says nothing about ordering, total counts, or what happens at range boundaries.

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, front-loaded with the output type and scope, with no wasted words. Brevity here shades into under-specification rather than verbosity, but the structure itself is clean.

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

Completeness2/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 values need not be described, but the tool has 8 parameters including a required nested reading_context and zero schema documentation. A single clause cannot make an agent confident about how to set reading_context or the families/rule_ids filters before calling.

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

Parameters2/5

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

With 0% schema description coverage across 8 parameters, the description carries the full explanatory burden and mostly fails. It only implies surah, ayah range, and paging; the required reading_context object (mode/basis/preceding/following), plus families and rule_ids filters, are never mentioned or explained anywhere in prose.

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 names a specific output ('per-rule candidate counts') and scope ('a surah or an ayah range'), which is more than a tautology. However, 'candidate counts' is unexplained jargon and the description never distinguishes this tool from the sibling analyze_qaloun_tajwid, so an agent cannot confidently pick between them without opening both schemas.

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, no exclusions, and no mention of alternatives. It does not tell the agent whether this is a light summary versus the heavier analysis performed by analyze_qaloun_tajwid, nor what preconditions (e.g., a known corpus/reading context) must hold.

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