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

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing: no read-only confirmation, no statement of the response shape or format, and no indication of cost or side effects. The only behavioral hint is that the content is informational (engines, caps), which is inferred rather than stated.

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?

It is a single short clause with no filler, so there is nothing to trim. The brevity is not the problem; the clause is under-specified rather than plainly concise, and the most decision-relevant information (what the tool actually returns or does) is absent.

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 an undocumented required parameter, no output schema, and no annotations, the description should supply return shape and usage context. It supplies neither, leaving the agent to guess what 'unit cap grade' means and how the result should be used.

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 0%, so the description should explain the single project_id parameter, and it does not mention it at all. The bare name project_id is conventionally guessable, which prevents a 1, but the description adds no scoping, format, or required-ness 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?

The description names the subject matter (per-language available engines and unit cap grades), which gives an agent a rough idea of what data comes back. But it is a noun phrase with no verb and no statement of operation, so it never says whether it retrieves, computes, or configures anything. It does not differentiate itself from siblings like oss_units_list or oss_inventory_build.

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?

There is no when-to-use statement, no prerequisites, and no reference to any of the ~29 sibling tools. An agent cannot tell from this text whether to call oss_capabilities before building units or whether oss_units_list already covers the same ground.

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 must carry the behavioral burden. It usefully discloses two non-obvious traits: reviewer must differ from the author, and a 'rejected' verdict creates an unconfirmed record (a side effect). It is silent on what 'confirmed' does, whether the review mutates the claim state, permissions, or idempotency, which is a meaningful gap for a mutation 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?

Very short and front-loaded: the purpose, the reviewer constraint, and the rejection side effect come before the Args block. The terse phrasing borders on cryptic but no sentence is wasted.

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 5-required-parameter mutation tool with no annotations and no output schema needs more: the meaning of 'note', what 'confirmed' triggers, and what the call returns are all unstated. The description covers only the rejection branch and one precondition.

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 0% across 5 required parameters, so the description must compensate. It explains the verdict values (confirmed/rejected) and adds a constraint on reviewer, but note, claim_id, and project_id receive no explanation at all, leaving most parameters undocumented.

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+object: independent review of important/critical conclusions (claims). An agent can tell it is a review/decision operation distinct from record/withdraw/pending siblings. It does not explicitly name any sibling for differentiation, keeping it below a 5.

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?

'important/critical 결론' implies the scope in which this tool applies, and the reviewer-id constraint is stated. However, there is no when-not guidance, no mention of alternatives such as oss_claim_withdraw or oss_claims_pending, and no statement of prerequisites beyond the reviewer constraint.

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 carries the full behavioral burden. It does disclose one useful trait — results are ordered with critical items first — but says nothing about whether this is read-only, how much is returned (the limit parameter implies truncation), or whether unseen items require paging.

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?

A single front-loaded sentence with zero filler; the ordering note is placed where it matters. It is efficient, though the brevity borders on under-specification rather than tightness.

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, no annotations, and 0% parameter documentation mean the description is the only source of context, and it provides one clause. Required scoping (project_id), result capping (limit), and read-only semantics are all absent for a tool an agent will call blind.

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 0%, so the description should compensate and does not: neither project_id (required, scoping which project's claims are listed) nor limit (default 50, presumably result cap) is explained anywhere. Only the ordering hint touches the output side, not the 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?

States a concrete resource ('독립 검토를 기다리는 결론 목록' = list of conclusions awaiting independent review) plus an ordering, so the operation is identifiable. However, it never distinguishes this from sibling tools like oss_claim_review or oss_claim_withdraw, which operate on the same claim concept, leaving ambiguity about which one to pick.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no reference to alternatives such as oss_claim_review for acting on a pending claim. The 'pending review' framing implies a queue view, but the agent must infer that on its own.

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 does disclose one meaningful side effect: unit grades are recalculated after withdrawal, and that completed units are eligible. It does not say whether withdrawal is reversible, whether a new claim should be filed afterwards, what permissions or state the claim must be in, or what the response contains.

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 short clauses, front-loaded with the action and scope, with no filler. The brevity is appropriate, though the compression in the parenthetical makes the intent slightly harder to parse quickly.

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 mutation tool with no annotations, no output schema, and three required identifiers, the description is thin. It omits precondition state, reversibility, post-withdrawal workflow, and any parameter guidance, leaving an agent unsure 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?

All four parameters (agent, reason, claim_id, project_id) have 0% schema description coverage, and the description mentions none of them. With low coverage the description is expected to compensate, but nothing is said about the identifier formats or the role of 'reason'.

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 ('결론 철회' / withdraw the conclusion I wrote) and adds a parenthetical clarifying what a withdrawal covers: an incorrect conclusion or an older revision re-submitted after a wording fix. It does not name or contrast with any sibling such as oss_claim_review or oss_claims_pending, so an agent must infer the distinction between withdrawal and the other claim tools.

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 implies the trigger condition (the conclusion was wrong, or a corrected version supersedes it) and notes that already-completed units may also be withdrawn. It never states prerequisites, when not to use it, or which sibling to prefer for review vs resubmission cases.

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 at all, the description carries the full burden, and it does disclose the most costly behavior: the first build is slow and results are cached afterwards. It omits permissions/prerequisites, whether a build replaces an existing CPG, and what the caller gets back — significant gaps for an expensive long-running mutation.

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 terse clauses with no filler, and the expensive-first-run caveat is front-loaded where it matters most. Density is good, though the telegraphic style pushes some needed detail out rather than compressing it.

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 an expensive, cache-aware build tool with no annotations, no output schema, and zero schema descriptions, the definition leaves too much open: rebuild semantics, prerequisite state (repo opened via oss_repo_open), expected duration/result, and how it relates to oss_dataflow_query are all unaddressed.

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 0%, so the description must explain all three parameters. It covers only `language` (omitted → main project language) and says nothing about `rebuild`, whose interaction with the caching note is precisely the ambiguous case, nor about what project_id must refer to.

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: builds a CPG for dataflow analysis using Joern, which clearly separates it from the sibling oss_dataflow_query (query an already-built graph) and from oss_inventory_build. It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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?

"처음 한 번 오래 걸리고 이후엔 캐시" implies the call is a one-time prerequisite that later reads reuse, which hints at when to invoke it. There is no explicit sequencing instruction (e.g. build before oss_dataflow_query) and no statement of when not to call it or how rebuild interacts with the cache.

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 burden. It does add genuinely useful context: results carry an evidence_id graded as L2 evidence, and zero flows is explicitly NOT proof that no flow exists (a limitations caveat). However it omits prerequisites (whether a prior oss_dataflow_build index is required), whether the operation is read-only, and any cost/latency expectations for a static-analysis query.

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 definition is front-loaded in a single dense clause, followed by a compact Args block and one caveat sentence. Nothing is padded, but the fragment style and parenthetical nesting make it slower to parse than it needs to be.

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?

The description covers the essential query shape, which is the biggest risk area, but with no annotations, no output schema, and no parameter documentation, it leaves the agent without prerequisites, return-shape beyond evidence_id, or a pointer to the referenced 'limitations' source. Adequate to attempt a call, not adequate to call confidently the first time.

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 0% and the queries parameter is declared as an untyped object array with additionalProperties:true, so the schema documents nothing. The Args example is therefore the only source of field semantics — it names path, line, sink, and max_flows and shows the sink is a regex with alternation. That is a substantial compensation, though the 'language' parameter and its default are left entirely unexplained.

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 analysis operation: value-flow (L2) reachability from a source (function-definition line to parameter, or call line to argument) to a sink call-name regex. This is concrete enough to distinguish it from oss_dataflow_build and the LSP tools. It loses a point because the phrasing is dense jargon and never states the resource being analyzed (a project/repo) explicitly in the opening clause.

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 source-to-sink formulation implies when the tool is appropriate (taint/reachability questions), but there is no explicit 'use this when X, use oss_dataflow_build / oss_lsp_call_hierarchy when Y' routing. Sibling tools with adjacent roles are named nowhere in the description, so the agent must infer the division of labor.

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 carry the burden. It discloses that the tool inspects installation state and emits guidance, implying a read-only diagnostic, but does not state side effects, whether it installs anything, or what the response looks like.

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 short units of text with the main purpose front-loaded and the parameter note following. No filler, though the Args block partially repeats what the first line already conveys about language scoping.

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 diagnostic tool with no annotations and no output schema, the description covers what is checked and how to scope it, but leaves the shape of the result (what 'installation guidance' output looks like) unspecified.

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 0% (the schema only declares `languages` as a nullable string array with no description), so the description is the sole source. It supplies a concrete example (["rust", "python"]) and the default semantics (all supported languages when omitted), which is meaningfully more than the schema provides.

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 names the resource (engine/LSP installations) and the operation (check presence and version, plus installation guidance), so the agent knows this is a diagnostic tool. It does not explicitly contrast itself with siblings like oss_capabilities, which could plausibly overlap, keeping it below a 5.

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 implies usage (run it to verify engine setup and get install instructions) and explains the scoping behavior of the optional languages arg. There is no explicit 'use this instead of X when Y' routing against the many sibling 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 are provided, so the description carries the full behavioral burden, and it says nothing about read-only semantics, what happens when evidence_id is unknown, or permissions. The parenthetical listing of returned aspects (provider/operation/location/limitation) is the only behavioral signal, which is thin for a tool with zero annotation coverage.

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?

It is a single short fragment with no filler, so nothing is wasted, but the brevity comes from under-specification rather than tight writing. The key content (what the detail contains) is buried in a parenthetical instead of being front-loaded as a statement of 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?

With no annotations, no output schema, and 0% parameter coverage, the description should explain both the lookup contract and the return shape; it does neither beyond naming four returned aspects. An agent could guess the call but would not know what to pass or what to expect back.

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 0%, so the description must compensate and does not: neither project_id nor evidence_id is mentioned, nor are their formats, provenance, or whether evidence_id is project-scoped. The only implicit hint is that a 'detail' lookup takes an identifier, which is not enough to disambiguate the two required strings.

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 identifies the resource ('근거 상세' / evidence detail) and enumerates what the detail contains (provider, operation, location, limitation), which is more than the bare name gives. But it is a noun fragment with no verb, and it draws no boundary against the many sibling tools (oss_graph_query, oss_dataflow_query, oss_claims_pending), so an agent cannot tell from the text alone which one returns evidence records.

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?

There is no statement of when to call this versus alternatives, no prerequisite such as needing an evidence_id obtained from another tool, and no exclusions. The agent must infer from the tool name that this is the follow-up lookup after a list or search operation.

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 exist, so the description carries the full burden and does not meet it. It never states whether classification overwrites prior labels, is reversible, requires special permissions, or produces any side effects — all material for a mutation 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?

Two short front-loaded lines plus an Args block — no filler. The brevity is purposeful rather than lazy, though the Args block could have carried the two undocumented parameters at no structural cost.

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 mutation tool with no annotations, no output schema, and 4 required parameters of which 2 are undocumented. The description leaves an agent unsure what paths accepts (single vs multiple, repo-relative?) and what project_id governs, which is a real gap for a fully-required-parameter write call.

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 0%, so description is the only documentation, and it covers only 2 of 4 parameters. It does add real value by enumerating the category values (doc/generated/vendored/secret/binary/asset/code/test), which the schema does not express as an enum, and clarifies that reason is mandatory justification text. project_id and paths are left entirely undefined.

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: '직접 분류' (directly classify) of '규칙으로 분류되지 않은(unclassified) 파일' — a clearly bounded scope. It does not name or contrast with sibling tools like oss_unknown_record/oss_unknown_update, so an agent must infer precedence among them.

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 phrase targeting 'files not classified by rules' implies the triggering condition (rule-based classification fell through), which is genuine usage guidance. But it names no alternative and gives no rule for when to prefer manual classification over recording an unknown.

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 carries the behavioral burden and does disclose important traits: evidence is verified against a fixed commit, invalid evidence is rejected, symbol_ids are marked as reviewed, and important+ severity requires independent review. However, it omits other relevant behavior such as mutation semantics, replacement behavior via the `replaces` parameter, idempotency, and permissions.

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 purpose is front-loaded in one sentence, followed by a compact Args list. The text is efficient and has little wasted language, though the Args list is incomplete relative to the full schema.

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 an 8-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is only partially complete. It covers the core evidence/severity behavior but omits required identifiers, replacement semantics, and return/response 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?

Schema description coverage is 0% and there are 8 parameters, so the description must compensate. It explains the key parameters `text`, `evidence` with both accepted shapes, `symbol_ids`, and `severity`, but leaves `project_id`, `unit_id`, `agent`, and `replaces` undocumented beyond their names.

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 action: recording a conclusion together with evidence. It adds specific scope via fixed-commit verification and rejection on invalid evidence, but it does not explicitly distinguish this tool from nearby siblings such as oss_unknown_record or oss_claim_review.

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 explains what evidence formats are accepted and that important/critical findings need independent review, but it does not say when to use this tool versus alternatives like oss_unknown_record, oss_claim_review, or oss_symbols_mark. With many sibling tools, the lack of explicit routing guidance is a significant gap.

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 behavioral burden. It usefully says the query is read-only, but it does not explain permissions, query scope, error behavior, row limits beyond the schema default, or what "이름 기반 해석이라 L0" actually implies operationally.

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 short and front-loads the main operation, so it is concise. However, the fragmentary style and unexplained abbreviations like "L0" reduce clarity rather than adding useful structure.

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 query tool with three undocumented parameters, no output schema, and no annotations, the description is too thin. It establishes only that this is a read-only Cypher query, but omits the graph model, expected Cypher scope, return shape, and parameter roles needed to invoke it confidently.

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 0% for all three parameters, and the description does not mention project_id, cypher, or max_rows at all. An agent gets no semantic help for required or optional parameters beyond their bare names.

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 operation: a read-only Cypher query over a structural map. It is not a tautology, but it does not differentiate this tool from sibling query tools such as oss_dataflow_query or oss_lsp_* tools, and the parenthetical "codebase-memory-mcp" plus "L0" is cryptic.

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?

There is no guidance on when to use this tool versus the many sibling graph, LSP, dataflow, or evidence tools. It also gives no exclusions or prerequisites, leaving the agent to infer routing from the name alone.

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 carries the full burden. It does disclose two valuable behaviors: auto-registration of unknowns for anything the engine cannot see, and that rebuild is rejected when units already exist. It says nothing about cost/duration, whether the run is synchronous, what state is created or overwritten, or what happens on partial failure — significant gaps for a heavy pipeline operation.

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 pipeline scope, followed by the failure-mode caveat and a compact Args block. Dense but every sentence contributes; no filler or restatement of the name.

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 and no annotations, so the description must fully explain the tool. It covers what is built but not what is returned (counts, job handle, status) or whether the caller must poll a sibling such as oss_repo_status afterwards — a real gap for a multi-stage build.

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 0%, so the Args block is doing real work: project_id is tied to its source tool (oss_repo_open), and rebuild is given actual semantics (recreate; refused if in-progress or completed units exist). Both parameters gain meaning not present in the bare schema titles. Minor gap: no default value or type hint restated.

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 operation and enumerates the five concrete stages it performs (file classification, structural map indexing, symbol assignment, unit splitting, entry-point collection), plus what it does with unparseable input. An agent can tell this is the pipeline that produces the inventory. It does not, however, distinguish itself from build-adjacent siblings such as oss_dataflow_build or oss_file_classify.

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?

Prerequisite context is implied rather than stated: project_id is 'the id returned by oss_repo_open', and rebuild is refused when in-progress or completed units exist. There is no explicit statement of when to run this versus the sibling builders, nor any sequencing guidance beyond the id provenance.

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 carries the full burden. It does disclose one non-obvious behavioral trait — "L1 근거로 기록됨" reveals this call writes an evidence record, not just a pure read — which is valuable. However, it says nothing about required project scope, whether the symbol must already be indexed, or what the hierarchy output looks like.

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 identity and mode semantics, then positional detail — no filler sentences. The "Args:" block is a slightly awkward tail but is short and adds the 1-based indexing fact.

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?

Five parameters, no annotations, no output schema, and 0% schema coverage is a heavy disclosure burden that this one-liner largely leaves unmet. The agent still doesn't know what comes back (a call tree? flat list?), whether it needs an indexed/inspected project first, or what path and project_id require.

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 0%, so the description must compensate. It covers the genuinely ambiguous parts: line/column are 1-based and point at the function-name position, and the meaning of direction's two values. It is silent on path and project_id, leaving two of five parameters undocumented anywhere.

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?

Names the specific resource (LSP callHierarchy) and disambiguates the two modes (incoming = who calls this, outgoing = what this calls). It doesn't contrast itself with the sibling oss_lsp_references, which is the closest alternative and the most likely source of mis-selection.

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?

"incoming(누가 부르나) / outgoing(무엇을 부르나)" effectively tells the agent which direction value to pick, which is genuine usage guidance for one parameter. But there is no statement of when to prefer this over oss_lsp_references or oss_lsp_definition, and no prerequisite or exclusion is given.

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 carries the burden alone. It does disclose a real behavioral trait the schema cannot — that results are persisted as L1 evidence — but says nothing about read-only vs mutating side effects, required repo state, or failure modes for an unresolvable position.

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 terse fragments, both carrying information (LSP operation, evidence recording), front-loaded. It is efficient rather than padded, though the terseness leaves little room for the missing semantics.

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, no annotations, and 0% parameter coverage mean the description should explain what a definition result looks like (a location) and what preconditions apply. Neither is present, so an agent must guess at the return shape and positional conventions.

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 0% across four required parameters (project_id, path, line, column) and the description adds no clarification — notably whether line/column are 0- or 1-based and what path form is expected. This is a significant gap for a position-based tool where off-by-one errors are common.

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 the operation (symbol definition lookup via LSP) in a recognizable way, so an agent can distinguish it from oss_lsp_references or oss_lsp_call_hierarchy by name alone. It is a noun phrase rather than an explicit verb and never names the siblings, so it falls short of a 5.

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?

No when/when-not guidance, no mention of prerequisites such as opening the repo first, and no routing to the references or call-hierarchy tools. The note about results being recorded as evidence is context, not 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?

No annotations are supplied, so the description carries the full burden. It does disclose two non-obvious traits: line/column are 1-based, and results are persisted as L1 evidence. It says nothing about whether the index must be built, whether results are truncated or ranked, or the failure mode for an unknown symbol, so the disclosure is partial rather than complete.

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 short sentences with the core purpose front-loaded and no filler. The evidence-recording note is a fragment but still earns its place.

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 four-required-parameter positional query with no annotations and no output schema, the description should describe what is returned (locations list, file/line/column shape) and the prerequisite repository/index state. It omits both, leaving an agent unable to predict the response.

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 0% across all four required parameters. The description only clarifies that line and column are 1-based; it never explains what path means (file containing the symbol) or what project_id selects, so most parameters remain undocumented in both places.

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 gives a specific verb+resource: retrieving all reference locations of a symbol via LSP, at a given position. It distinguishes the operation from siblings in principle (references vs. definition), but never names oss_lsp_definition or oss_lsp_call_hierarchy as the alternative, so the differentiation is left implicit.

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?

There is no statement of when to use this tool versus oss_lsp_definition or oss_lsp_call_hierarchy, and no mention of prerequisites (e.g. that a repository must be opened and indexed first). Usage must be inferred entirely from the tool name.

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 supplied, so the description carries the full burden. It does disclose the key non-destructive behavior — the ledger and clone are preserved, so follow-up analysis is possible — which is genuinely useful for judging safety. But it omits idempotency (safe to call twice?), error behavior for unknown/closed projects, and whether in-flight operations are terminated.

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 short sentences, front-loaded with the action and immediately followed by the critical non-deletion guarantee. Nothing is wasted, though it could be tightened slightly by naming the project_id parameter alongside the action.

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-parameter teardown tool with no annotations and no output schema, the description covers the most important consequence (artifacts survive) but leaves the parameter unexplained and error behavior unspecified. An agent could call it correctly but would be guessing about failure modes.

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 0% and the single required parameter project_id is never mentioned in the description. With only one parameter it is guessable, but the description adds no meaning about how the ID is obtained (e.g., from oss_repo_list or oss_repo_open) or what happens if it is stale.

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 action and target: closing the language server and DB connection. The parenthetical clarifies that persisted artifacts (ledger, clone) survive, which separates it from destructive cleanup semantics. It doesn't explicitly name oss_repo_open as its counterpart, but the intent is unambiguous against siblings like oss_repo_status.

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 implied — call this when finishing with a project — and the note that analysis can resume next time hints at the reopen path. However, there is no explicit 'when to call this vs when not to', no statement about prerequisites (must a repo be open first?), and no mention of what happens on an invalid project_id.

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 at all, the description carries the full burden, yet it discloses nothing about ordering, whether closed repos are excluded, scoping to a session, or what the listing contains. 'Opened' hints at a read-only enumeration but that is inferred, not stated.

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?

One short phrase with no waste, but it is under-specified rather than concise-and-complete. There is nothing front-loaded beyond the bare resource name.

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?

There is no output schema, so the description should convey what the listing returns (e.g., repository identifiers, paths, or open handles), and it does not. For a tool with no annotations and no return-value documentation, an agent lacks the information needed to use the result 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 no parameter semantics to explain; the baseline of 4 applies. The empty schema is consistent with the description's framing of a simple listing call.

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 Korean description '열어 둔 프로젝트 목록' translates to a list of opened projects, which identifies the resource but uses a noun phrase rather than a verb+resource. It does not distinguish itself from oss_repo_status or oss_repo_open, so an agent must infer that this enumerates currently open repositories.

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?

There is no statement of when to call this versus oss_repo_status or oss_repo_open; the 'open projects' wording only implies a listing context. No exclusions, prerequisites, or alternatives are named.

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 carries the full burden and discloses the important side effect: it creates an analysis-only clone isolated from the original working tree and pins a commit. It also explains the resulting id format, though it omits lifecycle details such as cleanup expectations and permissions.

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 action and followed by a compact Args list. Every sentence adds useful information without repetition or 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?

There is no output schema, but the description explains the derived id format and the clone isolation behavior well enough for correct invocation. It could be more complete by mentioning cleanup via oss_repo_close, permissions, or error behavior, but the essential context is present.

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 0%, so the description must compensate, and it documents all three parameters clearly: source accepts a local path or git URL, ref is a branch/tag/commit defaulting to HEAD, and name defaults to the repository name. It further explains that the actual id is derived from name plus the first 8 commit characters.

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: opening an analysis repository and pinning a commit. It also explains that an analysis-only clone is created, which distinguishes it from siblings like oss_repo_list or oss_repo_status. It does not explicitly name alternatives, so it stops short of a 5.

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 implied by '분석할 저장소를 열고' and the analysis-only clone, indicating this is an initial setup step before analysis. However, it does not explicitly say when to use this versus oss_repo_list, oss_repo_status, or oss_repo_close, nor does it state 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 are provided, so the description carries the full burden. It hints at a gate/verdict semantic (complete must be true) but never says whether the call is a read-only computation, whether it mutates analysis state, what happens when complete=false, or what the report contains. The single clause about 'complete' is a behavioral hint, not 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?

Two short sentences with no filler and no repetition — but the brevity here is under-specification rather than discipline. The gating point is front-loaded, which is correct.

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 annotations and no output schema, so the description is the only source of truth about a report tool that seems to gate task completion. It should describe what the two axes count, what the gates check, and what a caller should do when complete=false; none of that is present.

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 0% and the description says nothing about project_id or its expected form. With a single self-evident identifier the cost is small, but the description does not compensate for the coverage gap at all, and it certainly adds nothing beyond the schema's bare title.

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?

It names the resource — coverage measured on two axes (file and symbol) plus completion gates — so a reader gets the gist. But there is no verb (report? summarize? compute?) and no differentiation from the many sibling reporting tools (oss_report_features, oss_report_export), all of which likely cover similar ground.

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 only usage-like cue is the gating note that complete=true is needed for 'full analysis complete', which implies the tool is consulted before declaring a task done. There is no statement of when to call it versus oss_unit_complete, oss_unknowns_list, or oss_report_features, and no 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 are provided, so the description carries the full burden, and it does disclose that the tool produces Markdown and JSON artifacts and returns a path. However, it does not say where files are written, whether existing files are overwritten, or what permissions are needed for a write-style export.

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 short sentences with the format and the return value front-loaded; nothing is wasted. It borders on under-specification rather than being padded, so it earns a high but not perfect mark.

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, no output schema, and an undocumented parameter, the description is too thin: it omits which report is exported, which project scope project_id selects, and where the path points.

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 0% for the single required parameter project_id, and the description never mentions it. With the schema providing no meaning for the parameter, the description should compensate but adds nothing.

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 ('내보낸다' / exports) and resource (리포트 / report), plus the output format (Markdown + JSON). It does not distinguish itself from sibling report tools such as oss_report_coverage or oss_report_features, so the agent cannot tell which report is being exported.

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?

There is no guidance about when to use this tool instead of oss_report_coverage or oss_report_features, and no statement of preconditions. Usage must be inferred entirely from the tool name.

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 behavioral burden, yet it discloses nothing about whether this is a read-only operation, whether it scans/analyzes the repository (cost, latency), or how pagination via limit/offset behaves. The only content is a taxonomy hint, which does not describe 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?

It is short and front-loaded, but it is a fragment with no verb, so the brevity comes at the cost of under-specification rather than efficiency. A single additional clause naming the action and return shape would have cost little.

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 annotations, no output schema, and 0% parameter coverage, the description must compensate for everything and does not. An agent cannot determine the operation type, the meaning of required inputs, or the shape of the result from this text alone.

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 0% and the description never mentions project_id, limit, or offset. Three parameters, including the required project_id, are left entirely undocumented in both schema and 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 is a noun phrase ('기능 카탈로그' / feature catalog) that largely restates the tool name 'oss_report_features' without a verb stating what it does with project_id. The parenthetical list of entry-point categories (http / cli / main / scheduler...) is the only substantive addition, hinting at how features are classified, but an agent still cannot tell whether this lists, builds, or summarizes them.

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?

There is no indication of when to use this tool versus the closely related siblings oss_report_coverage and oss_report_export, nor any prerequisite or sequencing guidance. Usage can only be inferred from the word 'report' and the tool name.

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 behavioral burden. It does not state that this is a read-only lookup, whether the project must already be opened, whether results are cached or fresh, or what error behavior occurs for an unknown project_id.

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?

It is a single short noun phrase with zero padding, but it is a telegraphic fragment rather than a front-loaded sentence, so it errs toward under-specification rather than conciseness.

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 and no annotations, the description does at least enumerate the metadata fields returned, which partially compensates. Still missing are the meaning of project_id, read-only confirmation, and any relationship to oss_repo_open/oss_capabilities.

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 0% and the single required parameter project_id has no documentation in the schema or the description. The description never tells the agent what a project_id is or where to obtain one (e.g., from oss_repo_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?

The fragment names the resource (project metadata) and enumerates the contents (origin, commit, inventory timestamp, engine capabilities), so the resource is identifiable. However, there is no verb at all, and it is not distinguished from siblings like oss_capabilities or oss_repo_list, which plausibly return overlapping engine/capability or repo-listing data.

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?

No guidance on when to call this versus oss_capabilities (engine capabilities), oss_repo_list, or oss_repo_open. The agent must infer that this is a per-project status lookup from the name alone.

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 disclosure burden for a state-mutating tool. It states that symbols are marked reviewed-complete and that a reason is attached, but says nothing about reversibility, permissions, whether marked symbols are later excluded from analysis, or what the call returns.

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?

A single compact sentence with the qualifying condition front-loaded and no filler. It could be slightly clearer about the resulting state, but every clause earns its place.

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 5-parameter mutation tool with zero schema documentation, no annotations, and no output schema, the description is far too thin. It should explain the identifiers, what happens to marked symbols downstream, and the effect of the operation.

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 0% across 5 parameters. The description hints at the required reason (note) and that symbols are plural, but project_id, unit_id, and agent are entirely undocumented in both schema and description, so it fails to compensate for the coverage 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?

States a specific verb (mark) and resource (symbols) with a clear qualifying condition (symbols with no capture-worthy behavior such as getters or DTO field bundles) and the resulting state (reviewed-complete). It does not differentiate itself from siblings like oss_unknown_record or oss_finding_record, which also record judgments, so it stops short of a 5.

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 implies when to use it by describing the kind of symbol it targets (simple getters, DTO bundles), which is a real usage condition. But it offers no explicit when-not guidance and never names an alternative tool for symbols that DO have behavior worth capturing, leaving the boundary with the sibling record/review tools implicit.

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 carries full burden — and it does disclose two significant behaviors: a hard rejection path that returns a missing-symbols list, and an automatic side effect that creates unknowns when the target grade is unmet. That side effect is exactly the kind of contextual info that earns credit. What is missing is whether completion is reversible, what the returned payload looks like beyond the failure case, and what permissions or preconditions govern success.

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 short sentences, front-loaded with the core action before the failure and side-effect clauses. Nothing is padded. It is arguably too terse for the complexity of the operation, but not wasteful.

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 state-transition/mutation tool with no annotations, no output schema, and four undocumented parameters, the description covers only failure semantics. It leaves the agent guessing about the required summary text, the meaning of agent, and what a successful return looks like — significant gaps for a tool that also auto-creates records.

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 0% across four parameters, including the required project_id, unit_id, and summary. The description mentions none of them — not what summary should contain, not what agent defaults to or does. With zero schema help, the description must compensate and instead says nothing.

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?

"단위 완료" (complete a unit) names the action and resource, and the follow-up clauses sketch two gating behaviors. But it never says what a 'unit' is in this system or how this differs concretely from siblings like oss_unit_next, oss_unit_renew, or oss_unit_context. Purpose is inferable, not stated with precision.

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 rejection rule ("검토 안 된 심볼이 있으면 거부") implicitly tells the agent this is the terminal step after symbol review, which is useful usage context. However, there is no explicit when-not guidance, no mention of prerequisites such as claim review state, and no routing to alternatives such as oss_unknown_record when the call is rejected.

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 still discloses real behavior: pagination continuation, the fact that symbols and edges are truncated to the first page, and the confidence-0.5 filter gated on all_calls. It omits read-only-ness, error behavior for an unknown unit_id, and the effect of include_calls=false, so the burden is not fully carried.

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 compact sentences with the main content statement front-loaded and pagination rules following. No wasted prose, though the reference to names not present in the schema (next_offset, next_line) adds mild confusion rather than clarity.

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 six-parameter, no-annotation, no-output-schema retrieval tool, the essentials of pagination and content gating are covered. However, the meaning of include_calls and agent, and the shape of the returned record beyond next_line, are left for the caller to guess.

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 0% across six parameters, so the description must compensate. It usefully disambiguates offset as a line ordinal within the unit (versus the returned file:line next_line) and explains all_calls, but leaves agent, project_id, unit_id, and include_calls entirely undefined.

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 the resource precisely: unit code with line numbers, symbol list, and call edges with L0 evidence ids. That distinguishes it from list/graph siblings such as oss_units_list or oss_graph_query. It stops short of explicitly naming which sibling to use instead for a different view.

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 operational guidance (continue with next_offset when the code is large; symbols and edges appear only on the first page; low-confidence edges require all_calls=true), which implies when and how to call it repeatedly. But nothing states when to choose this over oss_unit_next or oss_lsp_call_hierarchy, and no exclusions are given.

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 at all, the description carries the whole burden; it does disclose two non-obvious traits — that the call is effectively idempotent per agent (returns the already-leased unit) and that distinct agents are required for parallel work. It omits important failure/behavior facts: what happens when no units remain, whether a lease expires or must be renewed, and that the call mutates server-side assignment state.

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 behavior is front-loaded in two short sentences, followed by a compact Args block where each line adds real information. Nothing is padded, though the Args block format is slightly redundant with the schema's own parameter list.

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?

There is no output schema and no annotations, yet the description never says what a leased "unit" contains (id, path, scope?) or how the caller learns of exhaustion. For a stateful leasing tool in a parallel-agent protocol, that leaves the agent guessing about the return contract and the terminal condition.

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 0%, so the description must compensate, and it partially does: it explains `agent` ("분석하는 에이전트 id, 서브에이전트마다 다르게") and gives the concrete `kind` values (code / asset / test) that the schema does not enumerate. But the required `project_id` parameter is never mentioned, leaving the most mandated argument unexplained.

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+object: "다음 분석 단위를 임대한다" (lease the next analysis unit), which tells an agent exactly what the tool returns. It is clearly distinct from siblings like oss_unit_renew or oss_unit_complete in spirit, but it never names them, so differentiation comes only from the word "다음".

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?

"이미 임대한 단위가 있으면 그것을 돌려줌" and "병렬 분석 시 agent 를 서로 다르게" imply the leasing workflow and the parallelism protocol, which is genuinely useful context. However, no alternative tool is named and there is no statement of when to call oss_units_list or oss_unit_renew instead, so usage has to be inferred.

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 carries full disclosure burden. It does add one non-obvious behavioral fact — implicit auto-renewal per call — which is real value beyond the schema. But it omits what happens if the lease expires (does the unit get released, do later unit calls fail?), whether renewal extends a timer or resets state, and what the call returns.

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?

A single front-loaded sentence with the action first and the qualifying condition in parentheses; nothing is padded. It is dense enough that a non-Korean reader gets little redundancy to fall back on, but structurally there is no waste.

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 mutation-style lifecycle tool with no annotations, no output schema, and three entirely undocumented parameters, the description is too thin. It answers 'when do I call this' but not 'what state does it require, what does it change, and what happens on failure', which is the minimum an agent needs to invoke it safely.

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 0% across three parameters ('project_id', 'unit_id', 'agent'), and the description mentions none of them. In particular the 'agent' parameter with default 'main' has no explanation anywhere, so the agent must guess at required identifiers.

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 an action and resource ('임대 연장' / lease extension), so the general intent is recoverable, and the parenthetical clarifies that renewal is normally implicit. However, it never explains what the 'unit' being leased is or what a lease represents in this system, so the purpose is only partially pinned down for an agent that has not seen the sibling tool family.

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 genuinely actionable guidance: renewal happens automatically on every tool call, so an explicit call is only needed when the agent is idling or thinking for a long stretch. That is a clear when-to-use rule. It stops short of stating failure conditions or naming alternatives for recovering an already-expired lease.

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 carries the full burden and discloses very little: it does not state that this is a read-only operation, does not mention pagination or default page size (limit=50, offset=0 in schema), and does not say what happens when status is null. The status-value list is the sole behavioral detail.

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?

A single short sentence, front-loaded with the resource and with the one useful detail (status values) in parentheses. Nothing is wasted, though the brevity borders on under-specification rather than tight writing.

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 paginated list tool with four parameters, no annotations, and no output schema, the description explains neither pagination behavior, nor what a 'unit' is, nor what the returned entries look like. Only the status filter is addressed.

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 0%, so the description must compensate — and it does add real value for one parameter by enumerating the valid status values (pending/in_progress/done), which the schema leaves as an unconstrained string. But limit, offset, and project_id get no explanation at all.

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?

Names the resource ('단위 목록') and implies a list operation, which does distinguish it from the sibling mutation tools (oss_unit_next, oss_unit_complete, oss_unit_renew). However, '단위' is undefined domain jargon and the verb is only implied, so an agent must infer that this is a read/list operation rather than one of the many other unit-related actions.

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?

No indication of when to use this versus oss_unit_next, oss_unit_context, or oss_unknowns_list. The only usage hint is the parenthetical status note, which describes a filter value rather than a selection condition.

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 exist, so the description carries the full burden. It does disclose one non-obvious trait: the same question+scope pair will not be duplicated. It omits what a duplicate hit actually returns (existing record vs. error), whether this is a write visible to other agents, and any permission or concurrency 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 behavioral guarantee is stated first, then a compact docstring block for the key params. No filler, though the Args-style listing is somewhat mechanical and drops the required fields an agent most needs.

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 9-parameter mutating tool with no annotations and no output schema, this is thin: no return value, no dedup outcome, no interaction with oss_finding_record/oss_unknown_update, and 5 of 9 params undocumented. It is also Korean-only while all sibling tools are English-named, adding mild selection friction.

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 0%, so the description must compensate. It does so usefully for domain (example values dataflow/dynamic-dispatch/etc.), severity (low–critical), required_level (L0–L3 meaning minimum evidence grade), and the recommended_probes object shape, but it never explains the two most important required params, question and project_id, nor agent, scope, or supporting_evidence_ids.

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 opening sentence names a concrete verb and resource: record things that could not be confirmed as 'unknowns'. That is a real action an agent can distinguish from listing (oss_unknowns_list) or updating (oss_unknown_update), although those siblings are never named explicitly, so the differentiation is inferred rather than stated.

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 condition for calling is implied by '확정하지 못한 것' (what could not be confirmed), which does give a usable trigger. However, nothing tells the agent when to prefer oss_finding_record, oss_unknown_update, or oss_unknowns_list, and no prerequisites (e.g. evidence required first) are given.

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 only that results are severity-ordered and paged, giving no indication of read-only safety, how pagination behaves (defaults 50/0 in the schema), whether an empty result is meaningful, or what happens with filters. For a bare tool with zero annotation coverage this is a significant 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?

A single short phrase with no filler and the two key behaviors (ordering, paging) front-loaded. It is efficient but so sparse that it reads as under-specification rather than disciplined brevity.

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?

Six parameters, a required project_id, four optional filters, no annotations, no output schema, and no sibling disambiguation – the description should do much more to be callable with confidence. It never says what an 'unknown' record contains or how results are shaped or truncated.

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 0%, so the description must compensate, and it does not: the four filter parameters (domain, status, severity, and their semantics) go entirely unexplained, nor is the role of the required project_id stated. Only '페이징' hints at limit/offset, which is the bare minimum implied by the parameter names themselves.

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 phrase '미확인 목록' (unconfirmed list) with '심각도순, 페이징' (by severity, paged) does tell an agent this is a paged listing of unknown/unverified items ordered by severity. However, it never states what an 'unknown' is in this domain or how it relates to siblings like oss_unknown_record / oss_unknown_update, and the verb is implied rather than stated. Minimum-viable identification of the resource, not a differentiating definition.

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?

No when-to-use guidance at all: nothing tells the agent to call this instead of oss_unknown_record (to add one) or oss_unknown_update (to resolve one), and no prerequisites such as a required project_id are mentioned. The agent must infer the workflow from sibling names alone.

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 at all, the description carries the full burden, and it does disclose two behavioral facts that matter: optimistic concurrency via expected_revision (mismatch yields revision_conflict) and the evidence-level requirement for verification. It does not state that this is a mutating operation or what it destroys/overwrites, nor what a successful response contains, and it is silent on six of the nine parameters that change behavior (status, note, add_supporting, add_contradicting, agent).

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?

Very short and front-loaded: the action is in the first line and the hard constraint in the second. The "Args:" docstring remnant is slightly rough but each line carries real information, with no 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?

A 9-parameter mutation with zero annotations, no output schema, and no schema descriptions needs far more than two documented arguments. Key questions – which fields the update may change, whether resolution closes the unknown, whether add_supporting/add_contradicting feed the evidence requirement – are unaddressed.

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 0% and `resolution` is an untyped open object in the schema, so the description's inline shape ({disposition, rationale, evidence_ids}) and its three disposition values are genuinely additive – without them the agent could not populate the object at all. Conversely, note, status, agent, add_supporting, add_contradicting and unknown_id receive no explanation anywhere, so half the surface remains opaque.

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?

"미확인 갱신·해결" names a resource (unknown items) and two verbs (update, resolve), so the general action is inferable. But it never distinguishes itself from siblings like oss_unknown_record or oss_unknowns_list, and "미확인" is left as internal jargon with no gloss. Purpose is recoverable but not sharp.

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 does encode one genuine precondition: a resolution with disposition=verified requires evidence at or above required_level. That is a real "when this will fail" rule. However, there is no guidance on when to use update vs. record vs. list, and no mention of what the withdrawn/out-of-scope dispositions are for.

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