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

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers side effects ('none'), authentication ('none'), rate limits, error cases, and output truncation to 5000 characters, giving the agent a complete behavioral picture.

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 core purpose, followed by compact, information-dense sections for usage, input, output, errors, side effects, auth, and rate limits. Every sentence earns its place without unnecessary filler.

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?

Even without an output schema, the description explains the return value format and truncation behavior. It also covers error cases, side effects, auth, and rate limits, making it fully actionable for an agent selecting and invoking the tool 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful relational semantics by stating 'provide either path or id,' which clarifies that the parameters are alternatives rather than independent optional fields. This is valuable beyond the individual parameter descriptions.

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 states a specific verb and resource: 'Fetch one public MisakaNet lesson by repository path or lesson ID.' It clearly distinguishes from siblings like misakanet_search, which is for discovery, and misakanet_write_lesson, which is for writing.

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?

The description explicitly tells the agent when to use this tool: after misakanet_search returns a promising result, or when a lesson is explicitly referenced. It also states a clear exclusion: 'do not use it for broad discovery,' which prevents confusion with search 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?

With no annotations provided, the description carries the full burden and covers behavior thoroughly: side effects (none), auth (none), rate limits (none), and the missing-task error case. It also explains the return shape as a ready-to-inject context block.

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 high-value information is front-loaded and the behavioral/output/error notes are compressed into scannable clauses. The input-semantics sentence is redundant with the schema, which keeps it from a perfect score.

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?

Even without a structured output schema, the description conveys the full return contract, parameters, error case, auth/side-effect/rate-limit profile, and intended invocation time. Nothing an agent needs to call this tool correctly 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%, so the baseline is 3; the description's input-semantics line mostly restates schema fields already documented (task required, domain optional filter, top_n default/max). It adds no meaningful new parameter meaning beyond the 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?

"Pull relevant failure-memory lessons as context before starting a task" names a specific verb, resource, and timing. It is clearly distinguished from generic search/lesson tools by the stated goal of building injectable context for the agent.

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?

The description gives explicit timing: "at the beginning of a coding session or before attempting a non-trivial operation." It does not explicitly name sibling alternatives or when-not conditions, so it misses the top bar for exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses side effects ('none'), auth ('none'), rate limits ('local stdio process only'), error cases ('missing intent'), and the output format ('JSON with risk level, matched lessons, and guards'). This is comprehensive behavioral disclosure beyond what annotations typically provide.

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 information-dense yet concise, with the primary purpose front-loaded and separate clauses for inputs, output, errors, side effects, auth, and rate limits. Every sentence earns its place, and the structure is logical and scannable.

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 tool with 2 parameters and no output schema, the description is remarkably complete: it covers purpose, usage, parameter roles, expected output, error conditions, side effects, authentication, and rate limits. There is nothing an agent needs to know to call it correctly that 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 description coverage is 100% with both parameters documented. The description adds minimal value by restating that intent is required and context is optional, but the schema already provides examples. It does not elaborate on semantics beyond the schema, so it stays at the baseline for high coverage.

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 states a specific verb ('Check risk level') and resource ('before executing high-risk operations'), and clearly distinguishes its function (matches intent against lesson triggers) from the sibling tools which are search, retrieval, and submission operations. It leaves no ambiguity about what the tool does.

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?

The description explicitly lists when to use the tool: 'before RAG builds, WSL/GPU tasks, bulk imports, or any operation that might fail.' This provides concrete context and implies it is not needed for safe operations, giving clear guidance without needing to mention alternatives explicitly.

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 present, the description fully discloses side effects ('persists registration record'), error behavior ('Error cases: none'), authentication requirements ('Auth: none'), rate limits ('one registration per session'), and return fields. It also clarifies the token's role in subsequent calls, so the agent knows the consequence of invoking this tool. This goes well beyond minimal behavioral disclosure.

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 compact but information-dense: each sentence covers one distinct fact (purpose, local vs remote, token usage, input, output, errors, side effects, auth, rate limits). The main outcome is front-loaded in the first sentence, with operational details following in a logical order. No filler or redundancy.

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 one-optional-parameter tool with schema coverage at 100%, the description covers all needed decision factors: when to call, what to pass, what to expect back, and constraints (rate limit). It even provides output field names despite no formal output schema. An agent could invoke this with no further lookups.

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 already documents agent_type with examples and the default, and schema coverage is 100%, so the baseline is 3. The description's restatement that agent_type is optional and defaults to 'unknown' adds no new information. It does tie the parameter to the returned output, but that is marginal.

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 precise action ('Register an agent') and the concrete outcome (node_id and token for remote MCP access). It immediately contrasts with local stdio MCP, distinguishing this tool from non-registration siblings. The purpose is unambiguous and does not require opening the schema.

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 tells the agent when registration is needed ('For remote HTTP MCP, call this tool first') and when it is not ('Local stdio MCP ... does not need registration'). It also gives the follow-up step (pass token as user parameter), clarifying the operational context. This is more concrete than typical usage 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?

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so thoroughly. It declares 'Side effects: none,' 'Auth: none,' rate limits, error cases (missing query, unavailable index, no matches), and explains the progressive disclosure behavior controlled by the detail parameter. This goes well beyond minimal and gives an agent a complete behavioral picture.

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 purpose and usage, then organized into labeled segments (Input semantics, Output schema, Error cases, Side effects, Auth, Rate limits, exclusions). Despite covering 8 parameters, every sentence carries actionable information, and the length is justified by the tool's complexity and lack of annotations.

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 search tool with 8 parameters, no output schema, and no annotations, the description covers all essential decision factors: output shape, error handling, side effects, auth, rate limits, and route to the sibling for full content. It even sets expectations for the optional vector backend and redaction requirements. Nothing an agent needs to call it safely and effectively 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 description coverage is 100%, so baseline is 3, but the description adds meaningful semantics: it clarifies query is required, explains top's default and result-count caution, describes detail's token sizes and use cases ('compact for broad scans, full only after narrowing results'), and explains explain's scoring components. This enriches the schema rather than merely repeating it.

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 opens with a specific verb and resource: 'Search MisakaNet's public failure-lesson index by error text, keyword, or topic.' It immediately differentiates itself from siblings by stating 'Use when you need to discover relevant lessons and do not already know a lesson ID' and pointing to misakanet_get_lesson for full content, making the tool's role unmistakable.

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?

The description explicitly states when to use this tool ('Use when you need to discover relevant lessons and do not already know a lesson ID') and names the alternative (misakanet_get_lesson for full content). It also warns against private log collection and instructs callers to use redacted snippets, providing clear selection and safety 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?

No annotations are present, so the description must carry the burden, and it does: it declares the side effect (writes to data/contribution_queue.jsonl), error cases (missing problem, duplicate submission), output schema fields, auth none, and rate limits. This goes well beyond minimal disclosure.

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?

Every sentence adds distinct information, and the internal labels (Input semantics, Output schema, Error cases, Side effects, Auth, Rate limits) make scanning easy. The most important purpose and usage information is 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?

For a tool with no annotations and no output schema, the description covers all invocation-critical aspects: inputs, output shape, errors, side effects, auth, and rate limits. Nothing an agent needs to call it safely and correctly 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%, so the baseline is 3; the description adds the default for kind (missing_lesson) and the required/optional split. It omits 'source' from its summary, but the schema already documents it, so this is a minor gap.

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 opens with a specific verb ('Submit') and resource ('a failure-case intake') and immediately states the triggering conditions ('no matching lesson exists or a lesson was stale/incorrect'). This clearly separates it from sibling tools like misakanet_search and misakanet_write_lesson.

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 explicit 'Use after misakanet_search fails...' and 'when the user resolved a problem not yet documented' triggers. It does not name exclusions or contrast with other submission tools like submit_usage/write_lesson, so it stops short of a full 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?

With no annotations provided, the description carries full behavioral disclosure. It states side effects ('currently returns a local placeholder report only'), error cases ('missing lesson_id'), auth ('none'), rate limits ('local stdio process only'), and output shape ('JSON with lesson_id, tool, outcome, and status'). It also flags the tool as '[Experimental]', giving the agent an honest expectation of reliability.

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 purpose, then organized into labeled sections: Input semantics, Output schema, Error cases, Side effects, Auth, Rate limits. Every sentence earns its place by disclosing a distinct behavioral or invocation detail. The structure makes it easy for an agent to parse.

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 and no output schema, the description is remarkably complete. It covers when to call the tool, required parameters, parameter semantics, expected response, failure mode, side effects, authentication requirements, and rate limits. For a 3-parameter experimental tool, nothing an agent needs to invoke or interpret the result 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%, so the baseline is 3. The description adds value by clarifying the intent of the 'tool' param ('tool names the calling client') and giving concrete outcome examples ('solved, partial, not-helpful, or another short status'). It also documents the expected output fields, which the schema does not. However, it repeats the 'lesson_id is required' schema constraint rather than adding new meaning.

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 opens with a specific verb and resource: 'Record that a public lesson helped with a problem.' This clearly identifies the action and object. It does not explicitly name a sibling, but the phrase 'submit usage feedback' meaningfully differs from the sibling list's read/search/write tools, so the purpose is distinguishable without opening the schema.

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?

The description provides explicit usage context: 'Use only after the user or calling agent explicitly chooses to submit usage feedback for a specific lesson.' This tells the agent exactly when the tool is appropriate. It does not mention when not to use it or point to alternatives, so it stops short of a full 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?

Despite no annotations, the description explicitly states 'Error cases: none. Side effects: none. Auth: none. Rate limits: none.' This fully discloses behavioral traits, leaving no ambiguity.

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 a single paragraph but well-structured with purpose, input semantics, output schema, and edge cases. It is concise without unnecessary words, though could be more structured.

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 lists all output fields (user, free_reads_used, etc.) and covers error, side effects, auth, rate limits. Fully complete for this 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 coverage is 100% with one parameter. The description adds value by explaining the default value and providing example identifiers (e.g., 'anon:iphash', 'token:xxx'), going beyond the 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 'Check current usage status and remaining quota' using a specific verb and resource. It distinguishes itself from siblings like misakanet_submit_usage, misakanet_search, and misakanet_get_lesson.

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?

The description gives a clear use case: 'Use to see how many free lesson reads remain and how many credits are available.' It mentions optional user parameter with default, providing 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.

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

With no annotations provided, the description carries the full burden, and it excels: it discloses the side effect (writes to data/contribution_queue.jsonl), auth requirements, error cases, the 75 quality threshold, duplicate-submission behavior, and the output shape. This is strong behavioral disclosure for a mutating tool.

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 dense but well organized: a front-loaded purpose sentence, a usage condition, then terse semicolon-separated sections for input semantics, output schema, errors, side effects, auth, and scope. Every clause carries distinct, valuable information without filler.

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?

This is a 9-parameter write operation with no annotations and no output schema, yet the description covers required/optional inputs, output fields, error conditions, side effects, auth, and process scope. It gives an agent everything needed to decide whether and how to 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?

Schema coverage is 100%, so the schema already documents all parameters; the description's required/optional summary adds only marginal convenience. However, there is an inconsistency: it lists token as optional while also saying a registered token is required and the schema property notes it is required for write_lesson, which slightly undermines the added value.

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 opens with a specific verb and object: 'Submit a complete, structured failure lesson.' It also defines the precise scope—lessons documenting the full failure→root cause→fix→verification chain—which clearly separates this from the search, get, usage, intake, preflight, and registration 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 clearly states when to use the tool: 'after resolving a problem and documenting the full failure→root cause→fix→verification chain.' It also notes the auth prerequisite (registered agent token, not anonymous), but it does not explicitly mention alternatives or when not to use the tool.

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