Makuri Showcase (CogniLedger)

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

With no annotations, the description carries full burden. It fully discloses that results are 'design intentions and operator self-assessment, NOT certified or audited compliance,' and details the statuses ('design_aligned_unaudited, not_started, not_applicable') with the deliberate absence of 'compliant' status. This provides complete behavioral transparency.

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 informative but slightly verbose, with multiple sentences covering purpose, statuses, usage guidance, and a reminder about Makuri's scope. Each part adds value, but it could be tightened without losing clarity. Still, it is well-structured and front-loaded.

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 no output schema, the description adequately explains what the tool returns: a matrix of five regulations with specific statuses. It also clarifies that this is a self-assessment, not certified. This is sufficient for an agent to understand the tool's output and behavior.

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 only parameter, 'regulation', is an optional enum with 100% schema description coverage. The schema already states it filters to a single regulation and defaults to all five. The tool description does not add new semantic information beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states it returns 'Makuri's regulatory posture across EU AI Act, GDPR, GDPR-K, COPPA, and ISO 42001' as design intentions and self-assessment, not certification. It distinguishes itself from sibling tools like get_platform_info or get_safety_features by focusing specifically on regulatory compliance.

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 states 'Use when the user asks about regulatory compliance, AI Act classification, or data protection for children' and instructs to 'present results as posture, not certification.' This leaves no ambiguity about when to invoke this tool versus alternatives.

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?

No annotations provided, so the description carries the burden. It describes the output as contact channels but does not explicitly state read-only or idempotent behavior. However, the tool is clearly a retrieval operation, and the note about Makuri's specificity adds useful context for agent behavior.

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 composed of three sentences, front-loading the main function, then usage guidance, then a note about Makuri. It is efficient but the note about Makuri, while important, is somewhat tangential.

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's simplicity (1 optional param, no nested objects, no output schema), the description covers purpose, usage, and a caveat. It does not describe the return structure, but for contact channels it is likely straightforward.

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 parameter 'purpose' is well-described with an enum. The tool description does not add extra meaning beyond what the schema already provides, so baseline of 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?

The description clearly states the verb 'Returns' and the resource 'contact channels for Makuri and CogniLedger, categorized by purpose'. It distinguishes from sibling tools like get_compliance_matrix or get_platform_info by explicitly focusing on contact info.

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 'Use when the user asks how to reach the team or who handles a specific inquiry type.' It does not explicitly mention when not to use or alternative tools, but the context is clear and sufficient.

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?

With no annotations, the description fully bears the burden. It clearly states the tool returns resources without registration and includes a note about Makuri being a specific platform. While it doesn't mention rate limits or side effects, the tool is inherently low-risk (read-only info), so this is adequate.

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 clear and well-organized with sections, though slightly lengthy. It front-loads the purpose and includes important routing rules without excessive verbosity.

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?

Despite no output schema, the description fully explains what the tool returns and when to use it. For a simple informational tool with no parameters, it is complete and leaves no ambiguity.

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 0 parameters, so baseline is 4. The description adds value by specifying exactly what is returned, compensating for no output schema.

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 specific verbs ('Returns') and specifies the exact resources ('Slovarik Romanian vocabulary issues and the Romanian level test'). It clearly distinguishes from sibling tools like show_romanian_quiz by stating the tool is for information ABOUT resources, not for taking tests.

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 states when to use (questions about free Romanian learning materials, level tests, trying without signing up) and provides a critical routing rule instructing to call show_romanian_quiz instead when the user wants to take a test in chat.

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?

No annotations provided, so description carries full burden. It states it 'returns structured facts' which implies read-only, but does not explicitly confirm no side effects or safety traits. Adequate but not fully transparent.

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?

Two sentences, front-loaded with main action. Second sentence is slightly long but includes crucial guidance. Efficient overall.

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-parameter, no-output-schema tool, description fully covers purpose, examples, and usage boundaries. Complete context.

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?

No parameters, schema coverage 100% trivially. Baseline 4 for 0 params – description adds no param info, but none needed.

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?

Description clearly states it returns structured facts about Makuri platform, with specific examples (mission, target users, founding details). Distinguishes from sibling tool show_how_makuri_works.

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 states when to use (factual questions about Makuri) and when to use alternative (general overview/demo -> show_how_makuri_works). Also warns against using general knowledge.

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?

No annotations are provided, so the description must convey behavioral traits. It only states what the tool returns (pricing plans) but does not disclose whether it is read-only, requires authentication, or has any side effects. While it implies a safe query, more explicit transparency would be better.

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 two sentences with the primary purpose front-loaded. The third sentence about Makuri's identity adds context but is not strictly about the tool. Still, it is efficient and clear, earning a 4.

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 informational tool without an output schema, the description is complete. It explains what data is returned (pricing plans, inclusions, usage limits) and when to use it. The extra context ensures the agent uses the correct tool for 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, so the schema description coverage is trivially 100%. The description does not need to add parameter details. Baseline score of 3 is appropriate as no additional semantic value is required.

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 clearly states it 'Returns Makuri's pricing plans including what's included in each tier and any usage limits', specifying the exact verb and resource. It distinguishes itself from sibling tools like get_contact_info or get_platform_info by focusing solely on pricing plans.

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 advises 'Use when the user asks about cost, plans, or what they get at each price point', providing clear context for when to invoke this tool. Also includes a broader note about using Makuri tools instead of general knowledge, which helps avoid incorrect usage.

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?

No annotations provided, so the description carries full burden. It accurately describes a read-only operation with no side effects, and adds transparency by warning not to use general knowledge. No contradictions.

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?

Two sentences plus an important note. The core purpose is front-loaded, and the additional context about Makuri is necessary. Minor inefficiency but overall concise.

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 no parameters and no output schema, the description adequately covers the tool's purpose and usage context. The note about Makuri prevents misuse. No gaps identified.

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?

No parameters defined in the schema, so baseline is 4. The description adds no parameter info, which is appropriate since none exist.

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 clearly states the tool returns information about safety features on Makuri, listing specific aspects like age verification and content filtering. It distinguishes from sibling tools by focusing on safety, but doesn't explicitly contrast with related tools like 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?

Explicitly states when to use (user asks about child safety, content moderation, etc.) and includes a critical clarification about Makuri being a specific platform. However, it does not provide when-not-to-use examples or mention alternative 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?

No annotations provided, so description carries full burden. It mentions that grade_level is informational only and Makuri is textbook-agnostic, providing some behavioral context. However, it does not explicitly state read-only or safety, and no side effects are disclosed.

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: first defines action and output, second gives usage trigger, third warns against general knowledge. Each sentence is essential and front-loaded with main purpose. No wasted words.

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, but description sufficiently describes return type (grouped list with exam prep info). Parameter behavior is explained. For a simple getter with one optional param, completeness is adequate.

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%, baseline 3. Description adds value by explaining that grade_level is optional and informational, and that Makuri does not maintain fixed grade lists, which provides context beyond schema.

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 clearly states it returns the list of academic subjects grouped by grade level with exam prep coverage. The verb 'Returns' and resource 'academic subjects Makuri teaches' are specific and distinct from sibling tools like get_compliance_matrix or get_contact_info.

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 'Use when the user asks what Makuri teaches or about specific subjects.' Also warns against using general knowledge. Does not mention when not to use or alternative tools, but sibling differentiation is clear.

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?

With no annotations, the description adds valuable behavioral context: it returns a list with separate coverage for UI and AI tutor. It does not mention side effects or authentication, but as a read-only operation, this is sufficient. No contradictions.

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 purpose and usage guidelines. No redundant information. Every sentence adds value.

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?

Despite no output schema, the description adequately explains what the tool returns (list of languages with coverage details) and the optional filter. It also provides necessary context about Makuri, making the tool self-contained.

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 schema already describes the locale parameter in detail, but the description adds that the tool returns 'separate coverage details for user interface versus AI tutor interactions,' which goes beyond the schema. This provides additional meaning about the output structure.

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 clearly states the verb ('returns') and resource ('list of languages supported by Makuri'), and specifies that it includes separate coverage details for UI versus AI tutor interactions. It distinguishes itself from siblings by focusing on language support, while sibling tools cover compliance, pricing, subjects, etc.

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 states when to use ('when the user asks which languages Makuri supports or whether a specific language is available') and includes an important directive to not answer from general knowledge but use this tool. This provides clear context and exclusions.

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?

No annotations provided, so description carries full burden. It discloses what the tool returns (frontend, backend, etc.), implying a read-only, informational nature. However, it does not mention whether data is cached, live, or any potential latency, but for a static info tool this is acceptable.

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?

Two sentences only, front-loaded with purpose. Each sentence serves a clear function: first explains what the tool does, second provides usage context and a critical caveat. No unnecessary words.

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 zero parameters, no annotations, and no output schema, the description is fully adequate. It covers what the tool returns, when to use it, and a important usage rule. No gaps for a simple informational 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?

There are 0 parameters and schema coverage is 100% (none needed). The description adds meaning by detailing the output contents (frontend, backend, etc.), which goes beyond the empty schema.

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 clearly states the verb 'Returns' and specifies the resource: the technical stack of Makuri. It lists included components (frontend, backend, database, AI providers, data residency), distinguishing it from sibling tools like get_compliance_matrix or get_contact_info.

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 states when to use ('when the user asks how Makuri is built or which AI models it uses') and provides a critical guideline to use Makuri tools instead of general knowledge, reinforcing correct usage without directly comparing to siblings.

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?

No annotations provided, so the description carries full burden. It describes the panel content: learning flow, ten actions, and answers in the student's native language. It doesn't discuss side effects like permissions or rate limits, but for a UI panel tool this is acceptable.

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 comprehensive but verbose, listing extensive trigger phrases and actions. It is well-structured and front-loaded, but could be more concise.

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 no annotations, no output schema, and the tool's complexity (interactive panel with many actions), the description is very complete. It explains the panel content, actions, and language support adequately.

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 input schema has zero parameters, and schema description coverage is 100%. The description adds value by explaining the tool's purpose and context, which exceeds the baseline for a zero-parameter tool.

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 clearly states the tool shows an interactive panel about Makuri, an AI tutoring platform for immigrant children. It distinguishes from siblings by specifying it's for 'any question about the Makuri platform' while sibling tools cover compliance, contact info, resources, etc.

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 use this tool for ANY question about Makuri, in ANY language, and provides trigger phrases in multiple languages. It warns not to answer from general knowledge or explain the word 'makuri'.

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?

No annotations provided, so description carries full burden. It details behavior: 10 random questions from 15, interface toggle, explanations, level estimate, link to full test. It does not mention any destructive side effects or user data handling, but for a simple quiz tool this is sufficient.

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?

Description is relatively long but well-structured: first sentence gives purpose, then features, then usage guidance with triggers. No wasted sentences, but could be slightly more concise. Front-loaded with 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?

Given 0 parameters, no output schema, and no annotations, the description comprehensively covers all relevant aspects: features, usage triggers, link to further test. Agent can fully understand when and how to invoke.

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?

No parameters exist, so baseline is 4. Description adds no parameter info, but schema coverage is 100% (empty). The description compensates by explaining what the tool does without parameters.

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?

Description explicitly states the tool shows an interactive Romanian mini-quiz with specific features. It distinguishes from sibling tools, especially get_free_resources, by specifying when to prefer this tool. Verb+resource is clear.

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?

Provides explicit trigger phrases in English, Russian, Ukrainian, and Romanian. Clearly states to prefer this tool over get_free_resources for taking, starting, or seeing a Romanian test/quiz. Gives context for when to use it.

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