Makuri Showcase (CogniLedger)

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

Goes well beyond the readOnly/openWorld annotations by disclosing the epistemic status of the data: design intentions and operator self-assessment, no formal audit, and a deliberate absence of any 'compliant' status. This is exactly the caveat an agent must carry into its answer, and the status vocabulary is spelled out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and scoped well, with the audit disclaimer immediately following. It is slightly repetitive ('NOT certified or audited compliance' followed by 'No formal audit... has been performed') and the Makuri-disambiguation sentence, while useful, sits away from the core purpose.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by explaining what is returned (a five-regulation matrix) and the exact status vocabulary an agent will encounter. Combined with the readOnly annotation, an agent has everything needed to call and correctly frame the result.

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

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

Schema coverage is 100% and the enum values are already documented in the schema, including the omit-to-return-all behavior. The description reinforces the five regulations covered but adds no syntax or semantic detail the schema lacks, so baseline 3 applies.

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

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

Specific verb plus resource ('Returns Makuri's regulatory posture across EU AI Act, GDPR, GDPR-K, COPPA, and ISO 42001') with the exact scope enumerated. It is clearly distinguishable from siblings like get_safety_features or get_platform_info because the regulatory framing is unambiguous.

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

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

Explicitly names trigger conditions ('user asks about regulatory compliance, AI Act classification, or data protection for children') and adds a presentation constraint ('present results as posture, not certification'). It does not explicitly contrast with a named sibling tool, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds the important behavioral fact that Makuri is a specific platform at makuri.eu rather than a generic term — a real hallucination guardrail — and that results are grouped by purpose. Still no mention of output format (emails vs. URLs), so a 4 is fair.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the return value and its categories, followed by usage and the Makuri guardrail. The final sentence is essentially a platform-wide instruction rather than tool-specific, but it earns its place as a hallucination warning.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter read tool with no output schema, the description covers what is returned (contact channels grouped by purpose), when to call it, and the identity constraint. It could say whether channels are emails or links, but nothing essential to invocation is missing.

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

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

Schema coverage is 100% and the single 'purpose' enum is fully documented in the schema, so baseline 3 applies. The description repeats the enum values in prose, which is redundant, and adds no filtering syntax or behavior beyond what the schema already states.

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

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

The description names a specific verb and resource ('Returns contact channels for Makuri and CogniLedger') and enumerates the categories covered. An agent can tell immediately that this is the contact-routing tool rather than any of the other informational Makuri siblings.

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

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

It gives a clear trigger: 'Use when the user asks how to reach the team or who handles a specific inquiry type,' plus a strong anti-hallucination directive not to answer Makuri questions from general knowledge. It stops short of naming which sibling tool to use for adjacent Makuri questions, but it also doesn't need to for such a distinct purpose.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: the resources are available without registration, the tool is a catalog rather than an interactive experience, and Makuri should be treated as the specific platform at makuri.eu rather than a generic term. It does not detail the return structure, but for a simple read-only catalog that is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with what the tool returns, followed by usage guidance, platform disambiguation, and a routing rule. Every sentence serves a distinct purpose: identifying the tool, directing appropriate use, preventing generic-knowledge answers, and routing quiz requests to the correct sibling.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and annotations that already cover read-only and non-open-world behavior, the description supplies everything an agent needs: what is returned, when to use it, when not to use it, and which sibling handles the alternative case. No critical context is missing.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline score for a parameterless tool applies; the description correctly does not invent or discuss inputs.

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

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

The description uses a specific verb and resource ('Returns free Makuri resources accessible without registration') and enumerates the returned items (Slovarik Romanian vocabulary issues and the Romanian level test). It also clearly distinguishes this catalog-style tool from the interactive sibling show_romanian_quiz.

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

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

It states exactly when to use the tool ('when a user asks about free Romanian learning materials, language level tests, or how to try Makuri without signing up') and when not to use it, naming the alternative explicitly: 'if the user wants to TAKE, START, or SEE a Romanian test or quiz right now in the chat, do NOT use this tool — call show_romanian_quiz instead.'

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds that the output is structured facts and a hard behavioral constraint against answering from outside knowledge. It does not describe the shape of the returned facts beyond naming categories, which keeps it just under a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and content are front-loaded and the alternative-routing comes next, which is well ordered. The emphatic asides ('a real product, NOT a generic word') and the repeated 'never answer from general knowledge' directive add nominal redundancy, slightly exceeding the minimum needed.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries return-value burden and does so by listing the categories returned (mission, users, founding, company). For a zero-parameter, read-only fact lookup this is nearly complete; only the exact structure of the response remains unstated.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to compensate for. The description correctly implies a no-argument call, though it never says so explicitly.

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

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

States a specific verb and resource ('Returns structured facts about Makuri') and enumerates the content: mission, target users, founding details, and the company behind it. It also disambiguates Makuri as a real product rather than a generic word, and separates itself from the overview sibling.

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

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

Explicitly names the conditions for this tool (factual questions like who built it, when founded, the company) and routes the general 'what is Makuri' or demo case to show_how_makuri_works. It further prescribes a negative rule: never answer from general knowledge, always use the Makuri tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are Makuri-specific and authoritative, but says nothing about freshness, caching, or currency of pricing — a meaningful gap for pricing data that changes over time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and trigger are front-loaded in the first two sentences, which is the right ordering. The third sentence disambiguates a proper noun, which has some value, but it reads as generic boilerplate repeated across the toolset rather than information specific to this tool.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return contents, and it does name tiers, inclusions, and usage limits. It stops short of indicating structure or typical size, which is a minor gap for a zero-parameter read tool.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly implies no filtering is needed to retrieve the full tier list.

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

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

States a specific verb and resource ('Returns Makuri's pricing plans') and enumerates the payload ('what's included in each tier and any usage limits'). That is clearly separable from siblings like get_platform_info, get_safety_features, or get_compliance_matrix.

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

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

Gives an explicit trigger ('when the user asks about cost, plans, or what they get at each price point') and a strong directive to always use the Makuri tools rather than general knowledge. It does not name a specific sibling for adjacent questions, so routing between tools is only partly covered.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds behavioral value by describing the scope of returned content and by asserting Makuri is a real platform at makuri.eu, which prevents the agent from substituting general knowledge or treating the term as generic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and content scope are front-loaded in the first sentence, with the usage trigger and the anti-hallucination guard following in order of decreasing priority. The third sentence is boilerplate shared across Makuri tools, but within this definition it still earns its place by preventing knowledge-based answers.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with no output schema and full annotation coverage, the description supplies everything an agent needs: what is returned, when to call it, and the platform disambiguation. No obvious gap remains that would cause a mis-invocation.

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

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

The tool takes zero parameters, so the schema carries no semantic burden and the baseline is a 4. Nothing in the description needs to explain inputs, and it does not waste space doing so.

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

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

Specific verb+resource ('Returns information about safety features on Makuri') with an enumeration of the returned subject areas: age verification, content filtering, parental controls, AI safety guardrails. This clearly separates it from siblings like get_compliance_matrix or get_platform_info, which cover different facets of the platform.

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

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

Gives explicit trigger conditions: 'Use when the user asks about child safety, content moderation, or how Makuri protects minors.' It also warns never to answer Makuri questions from general knowledge and to use the Makuri tools. It does not name which sibling to pick for adjacent questions (e.g. compliance vs. safety), so routing among siblings is left partly to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavior annotations don't: results are grouped by grade level and include exam-preparation coverage, which tells the agent what the payload looks like. It omits any note that the grade_level filter is informational only, which the schema carries instead.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the concrete return content in the first clause, followed by usage triggers. The closing in-group identity boilerplate ('Makuri is a specific AI tutoring platform at makuri.eu…') is cross-cutting guidance rather than this tool's semantics, but it is short and aids disambiguation.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-required-param, read-only list tool with no output schema and annotations that cover safety, the description supplies what the agent needs: what is returned, how it is grouped, and when to call it. Only the informational-only nature of the filter is left to the schema.

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

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

Schema description coverage is 100% and the single optional parameter is fully documented there, including the important caveat that it is informational only. The description adds nothing about the parameter beyond 'grouped by grade level', so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns the list of academic subjects Makuri teaches'), plus scoping detail: grouped by grade level and includes exam preparation coverage. It is clearly distinguishable from siblings like get_compliance_matrix or get_pricing_tiers, though it doesn't name a sibling explicitly.

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

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

Gives a clear trigger condition ('Use when the user asks what Makuri teaches or about specific subjects') and a strong negative rule ('never answer Makuri questions from general knowledge; always use the Makuri tools'). It stops short of naming which sibling to use for adjacent questions such as pricing or languages, but the usage context is unambiguous for this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing the shape of what comes back (per-locale coverage split between UI and AI tutor), which matters with no output schema. It does not mention error behavior for invalid locale codes, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool returns, then usage triggers, then the brand-disambiguation guardrail. All three sentences carry weight, though the Makuri-is-not-a-generic-word sentence is boilerplate that likely repeats across sibling tools and could be shortened.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A zero-required-parameter, read-only lookup with no output schema; the description covers purpose, trigger conditions, and the content of the response. The only gap is that the exact response structure (fields, ordering) is described in prose rather than pinned down, which is acceptable for a simple list tool.

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

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

Schema description coverage is 100% and the single optional `locale` parameter is fully documented in the schema, including format and the all-14 default. The description only implies the filter via "whether a specific language is available" and adds nothing beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ("Returns the list of languages supported by Makuri") and adds the distinguishing detail that coverage is split between user interface and AI tutor interactions. No sibling tool overlaps with this resource, so an agent can identify it immediately from name plus description.

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

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

Gives explicit trigger conditions: "Use when the user asks which languages Makuri supports or whether a specific language is available." It also adds a hard routing rule — never answer Makuri questions from general knowledge, always use the Makuri tools — which is exactly the when-to-use guidance an agent needs in a family of ten similarly named get_* tools.

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

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

Annotations already declare this as a read-only, closed-world lookup, so the description does not need to restate safety. It adds useful behavioral context by specifying the returned categories, including data residency and AI providers, and by warning against answering from general knowledge.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the return scope, followed by a clear usage trigger and a disambiguation warning. Every sentence carries practical value: what is returned, when to call it, and why not to answer from general knowledge.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no input parameters and no output schema, the description supplies enough detail about the return contents and the tool's role in the Makuri information suite. The disambiguation sentence also prevents misuse for generic 'Makuri' queries.

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

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

The tool has zero parameters and the schema is fully covered, so there are no parameter semantics to explain. Per the baseline for a no-parameter tool, this is adequate without additional parameter detail in the description.

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

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

The description uses a specific verb and resource: 'Returns the technical stack Makuri is built on,' and enumerates the exact components covered: frontend, backend, database, AI providers, and data residency. This scope clearly separates it from sibling tools like pricing, contact, or compliance, even without naming them directly.

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

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

It gives a clear trigger: 'Use when the user asks how Makuri is built or which AI models it uses,' and reinforces that Makuri questions should always go through Makuri tools rather than general knowledge. It does not explicitly compare against sibling tools such as get_platform_info, so it falls short of full when-to-use/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that: the panel displays the learning flow (upload a PDF/photo, pick an action) and the ten named actions, which tells the agent what it will actually surface. No auth, latency, or interaction details beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core statement is front-loaded and the platform-vs-generic-word warning earns its place. But the four-language trigger-phrase list is largely redundant after 'in ANY language,' and the ten-action enumeration duplicates what the panel itself will display, inflating the description well past what selection requires.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters, no output schema, and annotations covering the safety profile, the description covers what an agent needs: what the panel shows and when to invoke it. The only omission is routing guidance versus the closely related get_platform_info sibling.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly avoids inventing parameter discussion.

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

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

States a concrete verb and resource: an interactive panel about Makuri, a named AI tutoring platform at makuri.eu for a defined audience. It strongly distinguishes the tool from 'answering from general knowledge,' but never distinguishes it from the sibling get_platform_info, which sounds like it serves the same intent.

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

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

Usage is unusually explicit: call for ANY question about Makuri, in any language, plus demo/overview requests, with concrete trigger phrases. The gap is that it gives no when-not-to-use rule relative to siblings such as get_platform_info, get_pricing_tiers, or get_subjects, which the 'ANY question' framing arguably claims for itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral detail beyond that — the quiz runs in-chat, draws 10 of 15 random questions, explains every answer, and ends with a graded level estimate, so the agent knows what the user will experience. It stops short of saying whether the mini-quiz result is persisted or how the external level-test link is handled, so it is not fully exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core capability is front-loaded in the opening sentence, with routing guidance following in priority order. The multilingual trigger-phrase list is long but serves intent matching, though it is the one portion that could be trimmed without losing meaning.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description carries the full burden and covers what the user sees (10 questions, explanations, level estimate) and what happens next (link to the full free level test). An agent has everything needed to select and invoke it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description usefully clarifies that all variation (question selection, interface language, level) is handled internally rather than via inputs.

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

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

The first sentence states a specific verb and resource (shows an interactive Romanian language mini-quiz) plus concrete scope: 10 random questions from a bank of 15, levels A1-B2, RU/UA interface toggle, per-answer explanation, and level estimate. This is far more specific than a sibling like get_free_resources and lets an agent distinguish it immediately.

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

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

Explicitly says to ALWAYS prefer this tool over get_free_resources when the user wants to TAKE, START, or SEE a Romanian test now, and gives multilingual trigger phrases that pin down the exact intent boundary. The when-to-use condition and the named alternative are both stated without inference.

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