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

With no annotations, the description carries the behavioral burden well: it discloses the write requires permission to change tasks, that the note is signed with the assistant's name, and that a blank project scopes it globally. It also warns that every assistant reads both notes and decisions, implying visibility. It stops short of describing the response or what the note looks like once created.

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

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

Purpose is front-loaded in the first clause, and every sentence contributes routing or constraint information. The middle sentence is dense and slightly run-on ('those are decisions (fenbs_add_decision; a rule when it holds from now on)'), costing some readability, but there is 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?

For a 4-parameter write tool with no annotations and no output schema, the description covers the essential judgment call (fact vs decision), permission requirement, scoping, and the dedupe-first workflow. The only gap is what the caller gets back on success, which is minor absent an output schema.

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

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

Schema description coverage is 100%, so all four parameters already carry their own descriptions, including 'omit for everything' for project and a default for category. The description restates the blank-project behavior without adding format, length, or validation detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ("Leave a context note for the next AI assistant") and immediately defines what qualifies as a note versus a decision. It explicitly names the sibling tools it is not (fenbs_add_decision) and the ones that continue the workflow (fenbs_list_context_notes, fenbs_update_context_note), so an agent can route correctly without opening any schema.

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

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

Gives explicit when-to-use (a fact nobody chose, how code works, a trap, where something lives) and when-not-to-use (rules, preferences, anything a person decided or instructed). It names concrete alternatives and the condition selecting them: existing note -> fenbs_update_context_note, standing rule -> fenbs_add_decision.

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 delivers: standingRule consequences (shown at the top of every assistant's AI context and mandatory to follow), the supersedes side effect (the replaced decision becomes superseded), the open default, and a permission requirement ('Needs permission to change tasks'). It also clarifies the authority boundary that the agent records but never makes decisions.

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

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

Purpose and the rule-vs-question distinction are front-loaded, and each sentence carries operative guidance. It is longer than strictly necessary and some phrasing is repetitive, but there is little dead weight.

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 14-parameter mutation tool with no annotations and no output schema, the description covers the decision lifecycle, defaults, side effects, prerequisites, and required permissions, leaving nothing critical for correct invocation 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 coverage is 100%, so the baseline is 3, but the description adds workflow-level meaning beyond the schema by prescribing the coordinated use of fields (status decided + standingRule true + them in deciders + quoted reason) and by explaining the supersedes linkage when the new decision is decided.

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 precise verb+resource pair ('Record a decision, or ask a question for a person to decide') and immediately disambiguates the rule case. An agent can distinguish this from fenbs_add_context_note and fenbs_update_decision without opening any schema.

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

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

It states explicit conditions: record as a rule when the person says how something must always/never be done, 'never as a context note'; record decided only when a person decided it; add as open and ask when nobody has decided. It names fenbs_list_decisions as a prerequisite ('Search ... first') and names the context-note alternative to avoid.

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 does well: it discloses idempotent behavior (case-insensitive matching, existing project returned rather than duplicated) and a permission prerequisite ('Needs permission to change tasks'). It stops short of describing side effects like board placement or what the returned project 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?

Three tight sentences with the primary action front-loaded, followed by the safety/idempotency note and the permission requirement. Every sentence earns its place 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?

For a one-parameter tool with no output schema and no annotations, the description covers purpose, idempotency, and permissions adequately. The only mild gap is the shape of the returned project, which is minor given no output schema exists to defer to.

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

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

Schema coverage is 100% for the single 'name' parameter, so the baseline is 3, but the description adds meaningful semantics beyond the schema: the name is matched case-insensitively and ties to a repository. That raises it above baseline.

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 ('Add a project to the board') and immediately distinguishes itself from siblings like list_projects, rename_project, and delete_project. The 'one per repository' scope note makes the intent unambiguous.

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

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

It clarifies that the call is safe when the project may already exist and gives soft context ('usually one per repository'), which is useful. However, it never names an alternative tool (e.g., rename_project) or states when NOT to use it, so sibling routing is left to inference.

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

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

With no annotations, the description carries the full burden, yet it discloses nothing beyond the basic mutation. It doesn't say whether the comment is editable/deletable, whether permissions or auth are required, or what the task state implications are.

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 tight sentence with no filler and the verb+resource front-loaded. It is appropriately sized, though its brevity borders on under-specification rather than true 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?

For a mutation tool with no annotations, no output schema, and 0% parameter documentation, the description is too thin. It omits permissions, return behavior, and task-state effects that an agent would need 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 coverage is 0%, so the description must compensate. It loosely conveys that ref identifies the target task and that the added 'comment' corresponds to body, but it adds no format, syntax, or length details beyond the param 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?

States a specific verb (add) and resource (comment) with a scoping detail (to a task by ref). An agent can identify the operation, though it does nothing to distinguish itself from related sibling tools like fenbs_add_context_note or fenbs_update_item.

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, prerequisites, or alternatives are given. In a sibling set containing several note/comment-adding tools, the description provides no routing signal for choosing this one.

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 and does so thoroughly: it discloses permission requirements, duplicate-check behavior returning likely matches and created: false, free-board plan notices with upgradeUrl, and refusal behavior for full or read-only boards.

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 long but front-loaded with the core action and permission note, then moves through duplicate handling and edge cases without obvious filler. Given the 15 parameters and no annotations, the length is largely justified, though it could be structured more scannably.

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

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

Even without an output schema, the description explains the return shape via created: false, likely matches, plan notices, and upgradeUrl refusals. It covers permissions, deduplication, and downstream agent actions, leaving no major gap for an agent to call the tool correctly.

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

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

Schema description coverage is already 80%, so the baseline is 3, but the description adds workflow meaning beyond the schema, such as the combination of unlessSimilar: false with relatesTo to link a new task to a finished one. It also reinforces the note/plan separation and the key deduplication rule in context.

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

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

The description opens with a specific verb and resource: 'Add a task to a board.' It distinguishes the creation operation from siblings by explicitly referring to fenbs_comment and fenbs_update_item as alternatives when a match exists.

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 an explicit decision tree for when to create, when to comment on an open match, when to move a finished match back with fenbs_update_item, and when to call again with unlessSimilar: false. It also explains the automated-source key behavior and the permission requirement.

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 discloses that deletion is irreversible ('cannot be restored from fenbs yet'), requires permission to change tasks, and recommends update as the safer alternative when the note is only stale. It stops short of explaining the deletion mechanics or success response.

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 and the paragraph is appropriately sized for a destructive operation with important caveats. Most sentences earn their place, though the 'say which note you are deleting and why' instruction adds operational guidance rather than purely definitional 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?

Given no annotations and no output schema, the description covers the essential context: identification by id or exact title, irreversibility, the update alternative, and permission needs. It does not explicitly state that at least one of id or match must be supplied, though the schema and description together make that clear enough.

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

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

Schema description coverage is 100%, so the schema already documents both id and match, including case-insensitivity and duplicate-title refusal. The description repeats the identification options but adds no meaningful syntax or format details 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?

States a specific verb+resource (delete a context note), adds the condition that selects it (wrong or no longer applies, so assistants stop reading it), and distinguishes it from update_context_note by explicitly routing out-of-date notes to update instead.

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

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

Gives clear when-to-use and when-not-to-use guidance: delete when the note is wrong or no longer applies, update instead when it is merely out of date. It names fenbs_list_context_notes for finding the id, requires stating which note and why before deletion, and notes the permission requirement.

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 it discloses several non-obvious traits: the decision number is never reused, deletion is restorable via a sibling (implying a soft delete), and elevated permissions are required. It stops short of stating whether links/versions are immediately detached or how long restore remains available.

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?

Four short sentences, front-loaded with the action, then consequences, then the alternative, then prerequisites. Every sentence adds information, though 'Say why before you do it' is vague enough to be a slight drag.

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 destructive, single-parameter tool with no annotations and no output schema, the description covers the essentials: what is destroyed, that it is recoverable, and the permission gate. Missing only restore-window and cascade details, which are minor for this tool's complexity.

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 'ref' parameter, so the description must compensate and largely does not — it only repeats 'by ref' without explaining whether ref is an ID, a slug, or the 'number' alluded to later. The agent gets almost no additional resolution on the one input it must supply.

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+resource pair ('Delete a decision by ref') and immediately differentiates itself from the sibling fenbs_restore_decision, which does the opposite. An agent can distinguish this from get_decision, add_decision, and restore_decision without inspecting any schema.

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

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

It names the alternative path explicitly (fenbs_restore_decision brings the decision back) and states a precondition ('Needs permission to change tasks'), which is real routing guidance. However, 'Say why before you do it' is ambiguous — the schema has no reason field and additionalProperties is false, so it is unclear whether this is a workflow convention or a hard requirement.

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 does well: it discloses the soft-delete model, exactly what is retained (number, comments, followers, links), what is irreversibly destroyed (files), the reversal path via fenbs_restore_item, and the permission requirement. It stops short of describing behavior on missing refs, idempotency, or the response shape, so not a 5.

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

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

Three short, front-loaded sentences: identity, semantics, then preconditions. The 'Say what you are deleting and why' instruction is a behavioral nudge rather than tool mechanics, but it is brief and plausibly useful for an agent operating in a shared system.

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-parameter destructive tool with no annotations and no output schema, the description covers the critical facts: reversibility boundary, permanent file loss, restore alternative, and permission need. Only error/edge-case behavior on invalid refs is absent.

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?

One required parameter with 0% schema description coverage, so the description must compensate. 'Delete a task by ref' tells the agent that ref identifies the task, which is minimal meaning, but it adds no syntax, format, or example for the ref value.

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

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

States a specific verb+resource ('Delete a task by ref') and immediately differentiates itself from the sibling fenbs_restore_item by explaining this is a soft-delete that restore can reverse. An agent knows exactly which tool handles removal versus recovery.

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 names fenbs_restore_item as the undo path and adds a precondition ('Needs permission to change tasks'), which implies when the tool is appropriate. However, it gives no explicit when-to-use/when-not guidance or criteria for choosing deletion over flagging or archiving.

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 safety burden well: it discloses that tasks are not deleted, that orphaned tasks return on restore, that moveTo is permanent, and that task-change permission is required. It omits confirmation/error behavior and whether the project name must exist, minor for a delete.

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 core action, then behavioral detail in three compact sentences; the parenthetical sibling references add routing value rather than noise. Slightly dense run-on phrasing around the not-deleted/restored clause costs a point.

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 two-parameter destructive tool with no annotations and no output schema, it covers behavior, side effects, prerequisites and permission needs. Missing only confirmation guidance and any failure/error semantics.

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

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

Schema coverage is 100% (baseline 3), and the description exceeds that by explaining the semantic consequence of moveTo ("they move to that project for good") versus omission, which the terse schema text does not convey.

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?

Opens with a specific verb+resource ("Delete a project") and immediately scopes the blast radius by naming the counterpart sibling fenbs_restore_project. An agent can distinguish this from fenbs_delete_item or fenbs_restore_project without opening any schema.

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

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

Gives a concrete prerequisite (call fenbs_list_projects first to count tasks) and an explicit decision rule for the two modes: omit moveTo for a restorable soft delete, supply moveTo to permanently relocate tasks. It never states when NOT to delete or names a non-destructive alternative, so it stops short of 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses visibility semantics per mode, the required permission for 'business', and that it is refused on a personal board. It does not state what happens to an already-set flag or what the call returns, so it stops short of a 5.

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

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

Front-loads the action, but the sentence structure is tangled by nested quotes and a run-on that mixes mode semantics, permissions, and purpose. The final clause ('the note, plan and comments still say why') is useful but buried.

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?

Covers permission and visibility behavior well enough for a 3-param mutation with no annotations and no output schema, but omits the 'ref' format, default behavior for 'on', and any confirmation of what happens on success or failure.

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 only 33%, and the description compensates for the enum by explaining 'mine' vs 'business' in depth. However it adds nothing about 'ref' (format of the task reference) and only implicitly covers 'on' via 'take a flag off', leaving gaps.

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?

Starts with a specific verb+resource: 'Flag a task, or take a flag off.' No sibling tool performs flagging, so it is distinguishable. The awkward quoting around 'mine'/'business' slightly muddies the opening, keeping it from 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?

Explains when to use each mode: 'mine' for a private flag visible only to the acting user, 'business' for a team-visible flag requiring the 'Flag for everyone' permission and refused on personal boards. Gives the intended purpose ('look at this') but does not name alternative tools for capturing rationale.

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 does well: it discloses the return structure (Rules shown in full, context notes, counts of decisions/open questions, pre-approvals) and a critical behavioral constraint -- the Rules are binding and must be followed. It doesn't discuss permissions or limits, but for a read tool that is minor.

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 imperative and the ordering constraint, then flows through contents and the parameter. Slightly dense, but each sentence adds operative information rather than 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?

No output schema exists, so the description must convey what comes back -- and it does in detail (Rules, notes, counts, pre-approvals). Combined with the sequencing guidance, an agent has everything needed to call it correctly at the right moment.

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 already 100% on the single 'project' parameter, but the description adds real meaning beyond it: passing project augments board-level context with that project's own rules and notes, and it warns to scope to only the active project. This is value beyond the schema's terse 'by name' text.

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 (read) and resource (AI context for this board) and immediately distinguishes itself from siblings by naming the exchange it opens with (the Rules) and the call it follows (fenbs_whoami). An agent knows exactly what this retrieves versus fenbs_list_decisions or fenbs_list_context_notes.

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

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

Gives explicit timing ('before touching the work', 'straight after fenbs_whoami') and an exclusion ('only ask for the project you are working on'), steering the agent away from scanning all projects. This is when-to-use and when-not in the same breath.

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 the shape of the returned content (question, decision, rationale, decider, timestamp, linked tasks, versions), which helps an agent know what to expect. However, it says nothing about error behavior for an invalid ref, permission requirements, or whether earlier versions are included by default.

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 sentence, front-loaded with the resource and key, with the returned fields enumerated compactly. No filler, though the field list is dense rather than prioritized.

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 simple single-record read with one parameter and no output schema, the description covers what the tool returns and how to address the record. It is nearly complete; only error/permission behavior is 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 coverage is 0%, but the single 'ref' parameter is self-describing and the description supplies a concrete example format (DEC-004), which is meaningfully more than the bare string schema. This compensates well for the missing schema 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 names the resource (one decision) and the lookup key (ref), giving an example identifier format (DEC-004). It implicitly distinguishes itself from the sibling fenbs_list_decisions by specifying a single record, though the verb is elided.

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?

Using 'ref' to fetch one decision implies retrieval once you have an identifier, but there is no explicit statement of when to use this versus fenbs_list_decisions or fenbs_get_item, nor any prerequisite guidance. Usage is inferable but not spelled out.

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 load. It does add one useful behavioral fact beyond the schema — that comments are returned alongside the task — but it says nothing about permissions, behavior on a nonexistent ref, or output shape.

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 sentence with zero filler, and the essential lookup-by-ref information is front-loaded.

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

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

For a one-parameter read tool with no output schema, the description covers what the tool returns (task plus comments) and how to identify the target. Missing only minor details such as error behavior for an unknown ref, which is reasonable to omit at this complexity.

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 sole parameter is a bare 'string', so the description must compensate. The inline example 'FET-014' conveys the expected ref format, which is real added meaning over the schema, though it stops short of stating format rules or case sensitivity.

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 ('Get one task') plus the key detail that comments are included, and pins the lookup key as a ref. It is distinguishable from the list/search siblings by the singular scope, though it never names an alternative tool explicitly.

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

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

Usage is only implied: the agent can infer this is the tool to reach for when it already knows a task ref like 'FET-014'. There is no statement of when to prefer it over fenbs_search or fenbs_list_items, and no exclusions or prerequisites.

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 disclosure burden. It usefully discloses the access-filtered scope and that a role is returned per board, but says nothing about ordering, pagination, or whether it hits the network. For a zero-parameter read tool the risk is low, so this is adequate rather than rich.

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 no filler. The scope constraint and the returned field are both packed into the first clause an agent reads.

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

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

No output schema exists, so the description must hint at return shape; it does so by naming the role field. For a trivial zero-param list tool this is nearly sufficient, with only ordering/pagination left 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?

The tool takes no parameters, so there is nothing for the description to clarify. Baseline 4 applies; the description does not need to compensate for any schema 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 (List) and resource (boards), and adds scope ('you are a member of') plus return content ('the role you hold on each'). No sibling tool concerns boards, so differentiation is moot, but the purpose is unmistakable.

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

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

Usage is implied by the membership scoping ('boards you are a member of'), which tells the agent this returns only accessible boards. However, there is no explicit when-to-use guidance, no exclusions, and no named alternative among the many fenbs_list_* siblings.

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

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

With no annotations, the description carries the burden, and it does disclose the returned field set (title, project, category, author, timestamp, text preview) plus the truncation default of the first 200 characters. It does not state permissions or that the operation is read-only, but 'list' combined with the field disclosure makes the behavior clear.

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 tight sentences with zero padding, front-loading what the tool returns and its ids, then the truncation flag, then the sibling routing. 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?

No output schema and no annotations, yet the description effectively supplies the return shape and the truncation semantics, and it routes to the correct sibling. Nothing needed to call this two-parameter, zero-required read tool is missing.

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

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

Schema coverage is 100%, so both parameters are already documented; the description mostly restates them (full gives the whole text; project can be "everything"). It adds the useful framing that project-filters are about scope applicability, but that is marginal value beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource (list the context notes on this board) and immediately distinguishes itself from fenbs_get_context, which is described as the tool to read before working. An agent can tell these two apart without opening either schema.

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

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

Explicit routing: fenbs_get_context is "what to read before working; this is how to find a note to change." It also states the downstream purpose (ids needed by fenbs_update_context_note and fenbs_delete_context_note), so when-to-use is unmistakable.

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 and does disclose real traits: result ordering (newest first), the summary-vs-full distinction, and the semantic categories (rules, open questions, decisions a task depends on). It stops short of stating access/permission requirements (awaitingMe merely alludes to 'the person you act for') or pagination/limits.

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

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

Front-loaded with the resource and ordering, then usage triggers, then filters. Dense but every sentence carries weight; the definition of 'rule' is arguably necessary to interpret rulesOnly. Slightly long, but 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?

For an all-optional, 8-filter list tool with no output schema, the description supplies the conceptual model (rules, open questions, task-linked decisions) and workflow guidance. It leaves pagination, default result size, and cross-board scope unstated, which are the main remaining gaps.

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 63%, so the schema handles part of the load, but the description adds meaning to several params: q's 'DEC-4' example ('finds that one'), task as 'the decisions that task depends on', and rulesOnly as standing rules. It doesn't touch full, deleted, or awaitingMe beyond what the schema says.

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?

Opens with a specific verb+resource and scope: 'The board's decisions, newest first,' and defines what a decision record contains (what was decided, by whom, why, open questions). It also disambiguates 'rule' as a decided decision, which lets an agent separate this from fenbs_get_decision (single) and fenbs_add_decision (write).

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

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

Gives explicit when-to-use triggers: 'Search before changing anything that looks deliberate, before recording a new rule (one may already cover it), and before asking a question that may already be answered.' Strong context, but it never names the alternative tools (fenbs_get_decision, fenbs_search) or states when not to use it.

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

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

With no annotations, the description carries the full behavioral burden. It discloses only that this is a filtered listing; it says nothing about the required 'board' argument's role, result size or pagination, ordering, or whether hidden/done items are included by default. For a 7-parameter list tool with no safety annotations, that 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?

Two tightly written sentences, front-loaded with the core action and scope; the parenthetical terminology clarification is high-value and the filter list is compressed into a single clause. 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?

For a board-scoped list tool with no output schema and no annotations, the description covers what the tool does and what can be filtered, but omits pagination/result-size behavior and the meaning of the mandatory board parameter. Adequate but with clear gaps for an agent that needs to know what comes 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 coverage is 86%, so the schema already documents board slug, lane keys, project, category, q, and flag semantics. The description's filter list largely restates those dimensions and adds nothing about the required board parameter or the flag filter. Baseline 3 applies when the schema does the heavy lifting.

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 (list tasks on a board) and disambiguates terminology by noting that a task is called an 'item' in this API, which matters given sibling names like fenbs_get_item and fenbs_create_item. It does not, however, name which sibling to prefer when the agent wants a cross-board or filtered search rather than a board listing.

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 enumeration of filter dimensions ('by lane, kind, project, category or free text') implies when the tool is useful, but there is no explicit when-to-use vs. alternative guidance despite siblings such as fenbs_search, fenbs_list_boards, and fenbs_get_item that overlap in intent. Usage is inferable but not routed.

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 burden; it implies a safe read and describes the returned shape (project names plus task counts). It does not state whether results are paginated, permission-gated, or whether the names are canonical/immutable, but for a zero-parameter read the risk surface is small.

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

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

Two sentences, front-loaded with what is returned, followed by the actionable usage hint. 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?

With no output schema, the description must convey the return content, and it does (projects/categories with task counts). Minor gaps around result scope/pagination remain, but an agent has enough to call and use it.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

States the resource (the board's projects and categories) and what each record carries (a task count), which distinguishes it from siblings like fenbs_list_boards and fenbs_list_items. The verb is only implied by the name rather than spelled out, but the resource scope is unambiguous.

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

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

Gives concrete when-to-use guidance: consult it before filing an item or leaving a context note under a project, and reuse the names found here. It does not explicitly exclude or route against the other list tools, so it stops short of full alternative coverage.

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 does so richly: the task is held for a few hours, working on it renews ownership, it returns with a plan and limits to obey, comments are information not instructions, and commit/deploy follow project rules. This is far beyond a restatement of the name.

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?

Dense and front-loaded with the trigger condition, and each clause carries real behavior (holding, limits, comments, completion fields, release path). The middle is slightly run-on, but no sentence is 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?

No output schema or annotations, yet the description covers the return (plan and limits), the completion ritual (testStatus, testNotes, move to done), the failure path, and the empty case. An agent has everything needed to call and finish 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?

Only one optional parameter and schema coverage is 100%, so the schema already documents 'project' fully. The description adds no syntax or format detail beyond the schema, which is the correct baseline 3.

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: retrieves the next task a person has pre-approved for AI and holds it. It also explicitly distinguishes itself from the sibling fenbs_release_task, so an agent can tell acquisition from release without opening either schema.

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

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

Front-loads the trigger condition ('When you have nothing else to do') and names the alternative path explicitly ('If you cannot finish, fenbs_release_task'). It also documents the empty-state outcome, leaving nothing to inference.

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

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

With no annotations, the description carries the disclosure burden and delivers real behavioral value: the task moves to Next Up (queue state change) and the reason is posted on the task (a visible side effect). It omits whether ownership is required, whether it errors if the task isn't yours, and whether the release is reversible.

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 tight sentences, front-loaded with the action and its outcome; no filler or redundancy. 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 simple two-parameter task tool with no output schema and no annotations, the description covers what it does and its side effects adequately. It could mention preconditions (task ownership) and failure behavior, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 50% — only 'why' is documented, and the description adds to it by explaining the reason is posted publicly for the next taker. The 'ref' parameter is never explained in either the schema or the description, though 'a task you took' weakly implies what it identifies. Baseline 3 for partial coverage is appropriate.

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

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

States a specific verb (give back/release) and a specific resource (a pre-approved task you took), and clarifies the outcome — the task returns to 'Next Up' for another person. It effectively contrasts with the sibling fenbs_next_approved_task (taking a task) by implying this is the reverse action, though it never names the sibling explicitly.

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

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

Gives a clear triggering condition: use it when you took a pre-approved task and cannot finish it. There are no explicit exclusions or named alternatives, but the 'cannot finish' framing is a fairly precise when-to-use signal.

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 does well: it discloses the global rename effect, the conflict rule (refuses a name another project already has, preventing accidental merges), and an auth requirement ('needs permission to change tasks'). It does not mention reversibility or whether the old name becomes available, which keeps it from a 5.

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

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

Three short sentences, front-loaded with the core action and then the two most decision-relevant constraints. No filler; every sentence carries information.

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 or annotations exist, so the description must cover behavior, and it addresses scope, conflict handling, and permissions. It stops short of describing the return value or failure modes beyond duplicate names, a minor gap for a simple two-parameter mutation.

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

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

Schema description coverage is 100% with both parameters documented ('current name', 'new name'), so the schema already explains the inputs. The description adds no naming format, uniqueness, or length constraints beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb (rename) and resource (project) and clarifies the scope as 'everywhere it is used', which distinguishes it from add_project, delete_project, and restore_project in the sibling set. An agent can tell what this does without opening the schema.

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

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

The description implies the context (renaming an existing project) and states the permission prerequisite, but never explicitly says when to use this versus alternatives like add_project or delete_project, nor names any when-not conditions. Usage is inferable but not spelled out.

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 load and does well: it discloses that each signer receives an email, that the item sits in 'Awaiting sign-off' until all approve, that approval leads to 'Decided (and locked)', and that a permission to change tasks is required. It omits edge behavior such as a decline path, revocation, or re-request after rejection.

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 the first clause and the sentences are short. The conversational asides ('Say what was decided first', 'You can ask; you can never sign') carry information, though the em-dash-heavy aphoristic style costs a little economy.

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 or annotations exist, so the description must stand alone; it covers the lifecycle (Awaiting sign-off -> Decided/locked), notification side effect, and permission requirement. The main gap is the unexplained 'ref' identifier needed to target the decision.

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 50%: 'signers' is documented in the schema (and confirmed in the description as 'the complete list of signers, by email'), but 'ref' has no schema description and the description only gestures at it with 'Say what was decided first'. The description partially compensates but does not fully define what ref must point 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?

The first sentence gives a specific verb and resource ('Ask board members to formally sign a decision off') and clarifies the payload is the complete signer list by email. It is easy to tell apart from siblings like update_decision or add_decision, though it never names an alternative tool.

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 real context for use: 'Say what was decided first' establishes sequencing, and 'Needs permission to change tasks' establishes a prerequisite. It also rules out a tempting misuse ('you can never sign -- a sign-off is a person, signed in'), but offers no explicit comparison to 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 burden. It usefully discloses an auth prerequisite ('Needs permission to change tasks') and implies a mutation/recovery operation, but says nothing about idempotency, behavior on an invalid or non-deleted ref, 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?

Three short sentences, front-loaded with the action and resource, then the discovery hint, then the permission caveat. No filler or repetition.

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 mutation with no output schema, the description covers the action, how to locate the target, and the permission requirement. It leaves return behavior and failure modes unexplained, but the core calling information 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 coverage is 0% and the single 'ref' parameter has no format or constraint documentation in the schema. The description's 'by ref' only marginally signals that ref identifies the decision; it adds no syntax, expected shape, or validity guidance 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 (restore) and resource (deleted decision), which cleanly distinguishes it from fenbs_restore_item and fenbs_restore_project. It doesn't explicitly contrast with those siblings, but the resource specifier is unambiguous.

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

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

Gives the discovery path explicitly: 'fenbs_list_decisions with deleted: true shows them', telling the agent how to find the ref it needs. It does not state when restore is inappropriate (e.g., ref not deleted) or name alternatives, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that number, comments, followers, and links are restored but files are permanently lost, and that the caller needs permission to change tasks. These are exactly the non-obvious behavioral traits an agent needs before invoking.

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-loads the core action and packs substantive detail into three short sentences with little waste. The parenthetical about files is slightly clunky but earns its place by preventing a false expectation.

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 mutation with no annotations and no output schema, the description covers the key risks (partial restoration, files lost, permission requirement) and a related diagnostic tool. It is nearly complete, lacking only success/failure behavior or what the returned state looks like.

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 'ref' parameter is undocumented in the schema. The description only says restoration is 'by ref', which conveys that ref identifies the deleted task but adds no format, lookup, or validity details beyond that minimal hint.

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 (restore) and resource (a deleted task) and immediately scopes what restoration includes, so the agent can distinguish it from siblings like fenbs_delete_item, fenbs_restore_project, and fenbs_restore_decision. No ambiguity about what the tool does.

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

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

Clearly implies the use case (recovering a deleted task) and usefully notes that fenbs_get_item on a deleted ref reports it as deleted, which helps an agent confirm the preconditions before invoking. It does not, however, state when NOT to use it or what happens if the ref is not deleted.

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 the cascade effect on tasks, the name-collision refusal condition, and a permission requirement ('Needs permission to change tasks'). It does not describe the response or what happens to tasks that had been moved elsewhere, but the behavioral profile is unusually complete for an unannotated 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 short sentences, each carrying distinct information: purpose/cascade, discovery path, and failure precondition. Front-loaded with the action and zero 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?

With no output schema and no annotations, the description supplies the cascade semantics, lookup source, and refusal rule an agent needs to call it correctly. The only gap is the absence of any statement about the result of a successful restore.

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?

Only one parameter, and schema description coverage is 100% -- the schema already documents 'The deleted project, by name.' The description adds no format, disambiguation, or lookup guidance beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb+resource ('Restore a deleted project') and immediately clarifies the cascade scope ('with it every task that was not moved elsewhere when it was deleted'). This distinguishes it clearly from the sibling fenbs_restore_item, which restores an item rather than a project.

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?

Tells the agent where to discover restorable targets ('fenbs_list_projects shows deletedProjects') and gives an explicit precondition plus remedy path ('Refuses if a live project has the name -- rename that one first'). Both when-to-use and when-it-will-fail are covered.

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

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

No annotations are provided, so the description carries the full burden. It discloses the permission-bounded scope ('every board you can see'), but says nothing about read-only nature, pagination/result caps, matching semantics (substring vs full-text), or what fields are searched.

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, front-loaded sentence with no filler. Brevity is a virtue here, though it is arguably terse rather than complete.

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

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

For a search tool with no annotations, no output schema, and an undocumented query parameter, the description should explain matching behaviour and result limits. It leaves the agent unable to predict what a call returns.

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 single required parameter 'q' has 0% schema description coverage and the description never mentions it. 'Search' implies a query string, but format, operators, and matching behavior are left entirely to inference.

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 clear verb+resource ('search tasks') and adds scope ('across every board you can see'), which distinguishes it from the single-board fenbs_list_items. It does not explicitly name that sibling or what 'search' matches, but the intent is unambiguous.

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

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

The description gives no when-to-use or when-not guidance and names no alternative, despite fenbs_list_items and the various list_* tools existing as candidate alternatives. The scope phrase implies a use case but stops short of routing the agent.

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

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

With no annotations present, the description carries the full burden and delivers: partial-update semantics ('Only the fields you pass change; the rest are kept'), audit behavior ('Recorded in History under your name'), and an authorization requirement ('Needs permission to change tasks'). That is substantive behavioral context beyond the tool name.

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?

Four tight sentences, front-loaded with the action and its motivation before identification, update semantics, audit, and permission notes. No filler and every sentence carries a distinct piece of information.

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 mutation tool with no annotations and no output schema, the description covers the essential unknowns: mutation semantics, identification, audit trail, and permission needs. Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema description coverage is 100%, so every parameter including id/match/title/body/project/category is already documented with its own semantics. The description's restatement that the note can be named 'by id ... or by its exact title' duplicates the schema rather than extending it, so the baseline 3 applies.

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

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

States a specific verb (change) and resource (context note) plus the rationale for editing rather than adding. It explicitly distinguishes itself from the sibling fenbs_add_context_note by contrasting 'change ... instead of adding another that contradicts it', and points at fenbs_list_context_notes as the id source.

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

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

Gives explicit when-to-use guidance ('a context note that is out of date, instead of adding another that contradicts it') and names the alternative it replaces. It also explains the two valid identification paths (id from fenbs_list_context_notes, or exact title), leaving little to inference.

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

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

With no annotations present the description carries the full burden and does so well: it discloses partial-update semantics, that prior versions are retained whole, that deciders is a wholesale replacement while linkTasks/unlinkTasks are additive, and that changing tasks requires permission. These are exactly the mutation-risk facts an agent needs.

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?

Five compact sentences, front-loaded with the core operation and then the field-level semantics. Every sentence carries distinct operational information; nothing is padding.

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 16-parameter mutation tool with no annotations and no output schema, the definition covers the high-risk behaviors (partial update, history retention, list replacement, permission gate). Minor gaps remain around status-transition constraints and return behavior, but the essentials are 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 coverage is 75% and the schema itself documents most fields richly, but the description adds semantics the schema does not: replacement vs additive behavior for deciders, linkTasks and unlinkTasks. It adds real value beyond the structured data rather than restating it.

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

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

States a specific verb+resource ('Change a decision by ref') and immediately qualifies the scope as a partial update. This clearly separates it from fenbs_add_decision, fenbs_delete_decision and fenbs_get_decision.

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

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

Explicitly routes the agent away from this tool for substantive changes to a decided decision, naming the alternative ('record a new one with supersedes rather than rewriting history') and the permission prerequisite. This is a genuine when/when-not/alternative statement.

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 and does so well: it discloses that only passed fields change, that moving between lanes requires permission to move tasks, that content changes require edit permission, that plan and testNotes are replaced wholesale, and that existing links are retained. These details go well beyond the schema and clarify mutation semantics.

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

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

The description is dense but appropriately front-loaded with the core action. Each sentence adds practical guidance, though it could be slightly more scannable given the number of behaviors and parameters covered.

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 16-parameter mutation tool with no annotations and no output schema, the description covers permissions, partial-update behavior, replacement semantics, link handling, and testing guidance. It does not mention return values or every parameter, but the schema documents the remaining fields and no output schema exists to explain a return shape.

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 already high at 81%, so the baseline is 3. The description adds useful meaning for key parameters: plan is replaced entirely, relatesTo/unrelate modify links while keeping existing ones, size ranges from xs to xl with xl meaning split, and testStatus/testNotes should reflect what was and was not tested.

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

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

The description opens with a specific verb and resource: "Change a task by ref." This clearly identifies it as a partial-update operation and distinguishes it from siblings like fenbs_create_item, fenbs_get_item, and fenbs_delete_item, though it does not explicitly name any alternative tool.

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 clear usage context: set testStatus/testNotes when finishing, keep the plan current, and link/unlink tasks with relatesTo/unrelate. It also states permission prerequisites for lane moves and content edits, but it does not explicitly say when not to use this tool or name a sibling alternative.

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 full behavioral burden. It discloses that the tool returns identity and role information, and that it is a prerequisite for understanding permissions. However, it doesn't detail the return format or potential side effects (though it's likely a read-only operation). With zero annotations, more context could be given, but the description adds some value.

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

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

The description is two concise sentences, front-loaded with the core question and then the key usage guidance. Every word earns its place, and it's efficiently structured.

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

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

Given that there are no parameters and no output schema, the description provides sufficient context: what the tool does and when to call it. It could be slightly more complete by hinting at what 'allowed to do' entails (e.g., permissions), but overall it's adequate for an agent to invoke 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?

There are no parameters (0 params), so per the baseline, a score of 4 is appropriate. The description doesn't need to explain parameters, and it correctly avoids doing so.

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

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

The description clearly states the tool's purpose: revealing the caller's identity and their role on each board. This is a specific verb (whoami) and resource (identity/roles), distinguishing it from siblings like list_boards or get_item. However, it doesn't explicitly differentiate from every sibling, but the purpose is unmistakable.

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

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

It explicitly says 'Call this first — it tells you what you are allowed to do before you try.' This gives a clear when-to-use directive and implies it should be used before attempting other operations, guiding the agent on sequencing.

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