1lev1

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

Despite annotations covering the safety profile (destructiveHint=true, non-idempotent, closed-world), the description adds real behavioral context: PROFILE entries persist immediately with resources only added, WISH drafts stay drafts unless published on the site, supplier-answered rows are protected, and RIKMA yields a reviewUrl rather than being created. It omits concurrency behavior for expectedVersion and any error/conflict semantics, keeping it 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?

It is a single dense paragraph with the core action front-loaded, but the nested parentheticals and domain jargon ('what they set aside leaves it') make it harder to parse than necessary, and some clauses do not clearly map to an agent 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 destructive mutation with no output schema and fully undocumented parameters, the description covers entity-type outcomes but says nothing about return values, error handling, or what expectedVersion guards against. It is adequate on the 'what happens' axis and thin on the 'how to call it correctly' axis.

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 description never explains sessionId or expectedVersion. The URLs mentioned (siteUrl, reviewUrl) are not parameters of this tool, so the description contributes nothing to parameter meaning even though both required parameters are 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?

The description states a verb and resource ('Save a list') and then layers in entity-specific behavior for PROFILE, WISH, and RIKMA, which is more than a bare tautology. However, it never says the list is the assistant's staged items or connects to the start/revise/apply workflow implied by siblings like startAssistantTool and reviseAssistantTool, so the agent must infer the tool's role in the session lifecycle.

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 a partial when-not clause ('A RIKMA is never created here', supplier-answered rows are never changed here), but no positive statement of when this tool should be preferred over siblings such as setAssistantItemsTool or undoAssistantTool. The agent gets no trigger condition for invoking 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?

Annotations already declare readOnlyHint=false and non-idempotent/non-destructive, so safety is covered. The description adds genuine behavioral context by clarifying this only links pre-existing objects and requires a prior create step, which is not derivable from annotations or schema.

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

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

Two sentences plus a docs link; the core action is front-loaded and the create-first caveat is placed immediately after. The 'so what the rikma is pursuing and what it is actually doing about it stay connected' clause is rhetorical padding, but overall it is tight.

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 five-parameter mutation with no output schema but full annotation coverage, the description supplies the prerequisite workflow and object scope an agent needs. It omits expected behavior on repeated attaches (relevant given idempotentHint=false), which keeps it short of full completeness.

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 five parameters are already documented in the schema. The description loosely maps its prose to the entityType enum values but adds no format, id-sourcing, or naming detail beyond what the schema provides; 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 concrete verb (attach) and resource (an existing object to a process), and enumerates the object kinds it accepts (open mission, open resource, mission in progress, voted-on mission/resource). This lets an agent separate it from creation-oriented siblings, though the jargon ('rikma') adds noise rather than 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?

Explicitly gives the precondition ('It does not create the object: create it first') and names the alternative paths (prepareMissionTool, createTaskTool, or the URL the tool returns). Clear context for use; no explicit when-not condition, but the create-vs-attach split covers the main ambiguity.

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?

Goes well beyond the annotations: it discloses that rows are saved verbatim with no second model rewriting them, that nothing is actually created (only proposals the user approves at the returned reviewUrl), that invalid rows come back in `rejected`, and that `error.retryable` signals whether a retry helps. The idempotentHint=false annotation is given real meaning by the 'proposal' framing.

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 defining constraint and the sibling routing, and every sentence carries information. It is dense but no sentence is wasted; slightly long for a single paragraph, though appropriate given the schema complexity.

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 still covers the return surface (reviewUrl, `rejected`, `error.retryable`), the save semantics, and the alternative tool. An agent has everything needed to call this correctly and interpret the result.

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

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

Schema description coverage is 100% and the field descriptions are already detailed, so the baseline is 3. The description reinforces that every row needs both name and descrip and that violating this yields `rejected` rows, but it adds little else beyond what the schema already documents.

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 ('Create a planning board') plus the key qualifier 'from rows YOU already structured,' which immediately separates it from the AI-generating sibling planProjectWorkTool.

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

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

Explicitly names the condition that selects this tool ('when the conversation already holds the breakdown') and the alternative with its own condition ('Use planProjectWorkTool instead when the user only has a loose idea in free text'). Also states the projectId prerequisite.

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

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

Annotations give readOnlyHint=true and idempotentHint=true, but the description adds crucial context the annotations cannot: the tool returns a prepared link, nothing is created until the user approves, and the returned `url` must be presented verbatim. The nonprofit clarification is genuine behavioral context about how `profit: never` is interpreted by the system. This exceeds what structured fields convey.

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 and the 'nothing is created yet' caveat, which is good. However, the middle sentence about public support pages is lengthy and feels like promotional framing rather than operational guidance; it could be trimmed. The instruction to pass the URL verbatim is valuable, but the sentence order buries it after the nonprofit tangent.

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

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

Given no output schema and 8 parameters, the description does the heavy lifting: it defines the return value (a link), explains the lifecycle (prepared → user approves → created), warns against URL tampering, and disambiguates the nonprofit case. This is complete enough for an agent to invoke correctly without opening the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters. The description reinforces the `profit` enum semantics ('never' means selling is not the goal) and explains the public support page concept — which is parameter-adjacent context a first-time caller might miss. It doesn't add syntax or format detail beyond schema, keeping it at 4.

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 (prepare a form, return a pre-filled link) plus the key semantic correction that nothing is actually created yet. The term 'rikma' is defined inline and the distinction from any real creation is immediate. An agent can tell this apart from prepareSignup / prepareMission / startProcessTool siblings.

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

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

Clearly signals when to use: when a user wants to prepare a Partnership form. It also clarifies the nonprofit case ('A public-benefit or nonprofit initiative is a normal Partnership'). But it doesn't explicitly name a sibling alternative or state when NOT to use it (e.g. when the Partnership already exists — that's getProjectDetailsTool territory).

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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description discloses the approval workflow for acts assigned to others ('nobody is bound until they accept'), role-holder notification behaviour, and the caller membership prerequisite. These are non-obvious behavioural details not derivable from the structured fields.

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 purpose then bulleted decision shapes, which is well structured. The framing sentence ('Whenever the user wants something new to happen...') and the trailing docs link are mild padding, but nothing is genuinely wasteful for a 10-parameter tool with multiple modes.

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, a 10-parameter mutation tool is fully covered: prerequisite membership, required project ID, the two assignment modes, approval semantics, and a docs link. An agent has everything needed to choose and invoke 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?

Schema coverage is 100%, so the baseline is 3, but the description adds relational meaning the schema only partly encodes: which parameter set belongs to which mode (missionId paired with assignedUserId; tafkidims as the no-assignee path), and how getMemberMissionsTool / getProjectMembersTool resolve the IDs. It stops short of 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 and resource - create a task in a project - and immediately scopes what a task is ('the way a member gets something new done'). It explicitly contrasts itself with prepareMissionTool, so an agent can route between them 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?

Gives three explicit decision branches (existing mission -> create act linked to it; nobody does this kind of work -> use prepareMissionTool instead; no specific person -> create unassigned with tafkidims). When-not-to-use is stated as directly as when-to-use, with the named alternative tool.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false, so the agent knows this is a non-destructive mutation. The description adds genuinely new behavioral context: it is a private, per-user filter ('a filter for them only - nobody is told no'), which is not conveyed by any annotation.

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-load the effect, and the privacy clarification follows immediately. The trailing docs URL is useful and cheap. The phrasing is slightly informal but not padded.

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 mutation with a full annotation profile and no output schema, the description covers effect, scope, and privacy adequately. The only gap is how to obtain a valid openMissionId, which the docs link partially addresses.

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 is one required parameter (openMissionId) with 0% schema description coverage. The description's reference to 'an open mission suggested to them' implicitly ties the parameter to that mission, but it adds no format, source, or retrieval guidance beyond the schema's type.

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 concretely states the effect: a suggested open mission stops being suggested to the person. It is a distinct operation from siblings like findMissionTool or listMyWishOffersTool. It stops short of using a crisp verb+resource phrasing, describing the outcome narratively 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?

It implies the trigger condition ('the person says an open mission suggested to them is not relevant'), which gives usable context. However, it names no alternative tools or when-not-to-use guidance, so an agent must infer how this differs from related actions such as finding or applying to missions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds only the lookup-by-name behavior; it says nothing about match semantics (exact vs partial) or what happens when no mission matches.

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, purpose front-loaded, no wasted prose. The trailing docs link is minor filler but harmless.

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 read tool with rich annotations and a fully documented schema, the definition covers what an agent needs to invoke it. Return shape and no-match behavior are unaddressed but the annotations and simple schema make this acceptable.

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% for the single missionName parameter, so the schema does the heavy lifting. The description's 'by its name' merely restates the parameter without adding format or matching semantics.

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 (find), resource (mission), scope (for the user) and lookup key (by its name). It is distinguishable from list/get siblings at a high level, though it never names them 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?

No when-to-use guidance and no mention of alternatives such as getMissionDetailsTool, listUserMissionsTool, or getMemberMissionsTool. An agent must infer on its own whether this returns full details or just a handle.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond them: results are ordered newest-first, include creation time, and are paginated with hasMore/nextOffset. It does not disclose rate limits or result cap behavior, 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 sentences, front-loaded with the core purpose, followed by trigger conditions and pagination mechanics. Every sentence carries actionable information; nothing is redundant with the schema or annotations.

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

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

With no output schema, the description compensates by describing what comes back (projects with creation time, ordering, pagination cursor fields). All four parameters are covered by the schema, and usage triggers plus pagination are fully specified, leaving no gap an agent needs to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the pagination contract (when hasMore is true, call again with offset=nextOffset), which ties the offset parameter to a return value the schema cannot express since there is no output schema.

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

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

States a specific verb (find) and resource (the projects/rikmot the current user belongs to), plus ordering (newest first) and returned field (creation time). It is clearly distinguishable from siblings like getProjectDetailsTool, listProjectResourcesTool, or listRikmaProcessesTool.

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

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

Gives explicit trigger conditions: when the user mentions a project by name, wants to navigate to one, or just created one. It also states the pagination follow-up rule. It does not name a specific alternative sibling to avoid, so it falls just 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no note on whether timers are per-user only, no ordering, no freshness of the data, and no behavior of the includeDetails flag.

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 sentence, front-loaded with the core action, followed by a documentation link. No padding beyond the boilerplate URL, though the URL is not actionable for tool selection.

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 read-only lookup with rich annotations and no output schema, the definition is minimally adequate. It omits any description of what the returned timer records contain and how active is defined, which an agent would need since there is no output schema to consult.

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

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

Schema description coverage is 100% and the single includeDetails parameter has a documented meaning and default, so the schema does the heavy lifting. The description adds no semantics on top, which lands at the baseline for a fully covered 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 and resource with a scope qualifier ('currently active timers for the user'), which separates it from the sibling timerActionTool that presumably mutates timers. It does not, however, explicitly name the sibling or contrast behavior, 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?

The description gives no when-to-use or when-not-to-use guidance and never references timerActionTool, the obvious alternative for acting on timers. An agent must infer the intended context purely 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful context beyond that: it discloses the returned payload (rows, keys, status, version, recent changes) and the version-freshness motivation for calling it.

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, but the single sentence is dense and includes noise like the awkward parenthetical "(also from the site)" and an external docs URL. The core guidance survives, but the prose could be trimmed without loss.

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

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

With no output schema, the description carries the burden of describing returns and does so (rows, keys, status, version, recent changes), which is the key missing piece for a read tool. The only residual gap is the undocumented sessionId parameter and the unclear relationship to other read siblings.

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%: kind has an enum with a short description, while sessionId is undocumented. The description partially compensates by naming the kind values (rikma blueprint, profile, wish) and implying "latest session" semantics, but sessionId remains unexplained in both schema and description, so this sits at the 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 ("Read the person's current draft list on 1lev1") and enumerates the three kinds (rikma, profile, wish), which distinguishes it from write-oriented siblings like setAssistantItemsTool. It does not, however, clarify how it differs from getWishDetailsTool or listRikmaProcessesTool, so it falls short of full sibling differentiation.

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 gives a when-to-use condition with an alternative: "Call it before setAssistantItems when you are not sure you have the latest version." That is actionable routing guidance, though it covers only one sibling and offers no when-not guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine workflow behavior: that output feeds a missionId into createTaskTool and that tasks require a mission-in-progress. It does not describe pagination or return shape, but that is a minor gap given the annotations.

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 purpose, then the workflow reason, then the alternative, in three tight sentences. The docs link is the only optional element and every sentence 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?

With no output schema, the description still conveys that the result is a set of missions from which a missionId is selected, which is enough to use it correctly. It stops short of naming return fields, but the workflow framing compensates well.

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, establishing a baseline of 3. The description clarifies that userId is 'the assignee (a person)', which reinforces but does not extend the schema's own description, and adds no format or constraint details.

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 a project member's in-progress missions') with the scoping qualifier 'in-progress' that narrows it meaningfully. It does not explicitly contrast with the close sibling listUserMissionsTool, so it falls short of full sibling differentiation.

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 ('call this after choosing the assignee... to pick the missionId to pass to createTaskTool') and an explicit when-not with an alternative ('If no mission in progress covers the work... prepare a mission with prepareMissionTool instead'). Both the trigger condition and the fallback sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds a useful note that the payload includes tasks, timeline, and status, but says nothing about error behavior for an invalid/unknown missionId or about response size.

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 payload contents listed immediately, followed by a documentation link. No filler, though the bare URL adds little routing value for an agent.

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 read-only single-parameter tool, the description covers what the tool returns, which partly compensates for the absent output schema. Missing only edge-case behavior (invalid ID, permissions), which is minor 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?

Only one parameter exists and the schema documents it fully at 100% coverage ('Mission ID to get details for'). The description adds no format, prefix, or lookup guidance beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb ('Get') and resource ('detailed information about a specific mission') and enumerates the content returned (tasks, timeline, current status). This distinguishes it from listUserMissionsTool and getMissionStatsTool, though it never explicitly names those siblings as alternatives.

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 guidance or comparison against the many mission-related siblings (findMissionTool, getMissionStatsTool, getMemberMissionsTool, listUserMissionsTool). 'A specific mission' weakly implies you must already hold a mission ID, but the agent must infer this.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds a partial view of what the result contains (counts by status, time spent), but does not describe aggregation scope, whether counts are per-project or global, 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?

Two compact sentences, front-loaded with the purpose and followed by a docs link. Nothing is wasted, though the trailing URL adds little for an agent that already has the 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?

There is no output schema, so the description should carry more of the return-value burden. It gestures at the return shape ('counts by status, time spent, etc.') but leaves the 'etc.' vague and never clarifies scope (global vs per-project) or result size.

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 exists and its schema description ('Get stats for specific project only') is fully covered at 100%. The description adds nothing about projectId or its default behavior when omitted (presumably all projects), so baseline 3 applies.

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

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

States a specific verb and resource ('Get statistics about user missions') and names the kind of data returned (counts by status, time spent). It implicitly distinguishes itself from siblings like getMissionDetailsTool and listUserMissionsTool, but never explicitly states the difference.

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 guidance and no mention of alternatives such as getProjectStatsTool, getMissionDetailsTool, or listUserMissionsTool, which are the closest siblings. The agent must infer that this tool is for aggregate stats rather than listing or detail retrieval.

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

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds substantially more: it explains that mutations happen on the site, that sentences must be relayed verbatim without rewording figures, that silenceApproves deadlines auto-approve, and that `unavailable` sections must be reported as unread rather than empty. That is genuine behavioral context beyond the structured fields.

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 dense and long, but front-loads the core purpose and then groups the return fields (waiting, work, whatsNew, suggestions, unavailable) with actionable instructions. Almost every clause carries information an agent needs, though the volume pushes against easy scanning.

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 carries the full burden of explaining the return payload, and it does so thoroughly for a multi-section, complex aggregation tool. An agent has enough to call it and interpret every response section 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 100%, so lang, limit, rikma, and projectId are already fully documented in the schema, setting the baseline at 3. The description only lightly maps to parameters via the 'rikma X' scenario and the language instruction, adding marginal value over 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 aggregation purpose: 'what waits for the user and what is new for them' across rikmas, wishes, and deals. It is clearly distinguishable from point-lookup siblings like findUserProjectsTool, listMyWishesTool, or getMissionDetailsTool, which each cover only one slice of what this digest rolls up.

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 invocation phrasings ('what's new today', 'what is waiting for me', 'what is happening in rikma X'), which is strong when-to-use guidance. It stops short of naming a sibling alternative or stating when not to use it (e.g., single-item lookups), so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond a docs URL — no note on what the response contains or how fresh/authoritative it is. Baseline credit for a safe read with no additional behavioral insight.

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 stating purpose, scope, and a docs link, with zero redundancy. Nothing could be removed without losing 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?

With no output schema, the description hints at content ('goals, and features') and points to docs, which is reasonable for a trivial no-param info tool. It stops short of describing the actual return shape, but that gap is minor given the tool's simplicity and its safety annotations.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a no-param tool with an empty schema.

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

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

States a specific verb ('Get') and resource ('general information about the 1lev1 platform, its goals, and features'), which clearly sets it apart from the mission/project/task oriented siblings. No explicit sibling differentiation is offered, but the meta/info nature makes it 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?

Usage is only implied: an agent should call this when it needs platform context. There is no explicit when-to-use, no exclusions, and no reference to any alternative tool. Acceptable but minimal.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, but the description adds real behavioral context: the permission-scoped return ('For a rikma the user is not a member of, only the public face is returned (isMember:false)') and the cost/latency characterization ('it is cheap'). It does not describe pagination or output shape, but for a read tool with full annotation coverage this is strong added 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?

Front-loaded with the core purpose, then usage guidance, then the membership caveat, then a docs link. The long enumeration of returned fields is somewhat dense but earns its place by summarizing a return payload that has no output schema. Minimal 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?

With no output schema, the description carries the burden of describing returns and does so by listing the returned entities (members, roles, missions, resources, products). It is nearly complete; only the shape/format of those returns and any pagination behavior are unspecified, which is minor for a single-parameter read tool.

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

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

Schema description coverage is 100% and the single parameter (projectId) is documented in-schema as coming from findUserProjectsTool. The description adds nothing about the parameter, so the baseline of 3 applies when structured data 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 ('Get the facts about one rikma (project)') and enumerates the exact facts returned, immediately distinguishing it from scanProjectDirectionsTool by contrasting 'returns facts' with the latter. An agent can select it without opening a 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 guidance ('Call this before planning or writing anything in a rikma') and names the alternative tool along with the reason to prefer this one ('it is cheap and returns facts, unlike scanProjectDirectionsTool'). Covers both the condition and the exclusion.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: this is a prerequisite lookup step feeding createTaskTool, and the query param filters by name. It does not describe the shape of the returned member/role list, which is the remaining 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?

Three sentences, front-loaded with what the tool returns, then the workflow reason, then the edge case. The docs link is placed last and costs nothing. No sentence is redundant.

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 read-only lookup with no output schema, the description covers purpose, routing and the follow-up call adequately. What is missing is any hint of the return payload (e.g. that each member/role comes back with an ID), which the agent needs to chain into createTaskTool.

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 both parameters (projectId, query) are already documented in the schema and the description need not repeat them. Its mention of 'pass their IDs as tafkidims' refers to createTaskTool's parameters rather than this tool's, so it adds no additional semantics for the two inputs here.

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 people (members) and roles (tafkidim) of a project') and immediately scopes it to a distinct concern that no sibling covers. It also introduces the domain term 'tafkidim', which removes ambiguity about what 'roles' means in this system.

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

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

Explicitly names the trigger ('resolve a task assignee ... before calling createTaskTool') and the alternative branch ('for a task with no specific person, pick the roles that fit it here and pass their IDs as tafkidims'). This is a when-to-use plus a when-to-use-differently, which is the strongest form of routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds scope context beyond the annotations: it is members-only and excludes financial data, and it clarifies the trailing-window semantics of the counts.

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 verb and the metric list, then usage, then a docs link. The enumeration is long but justified because there is no output schema; the trailing docs URL is the only low-value element.

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

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

With no output schema, the description carries the return-shape burden and does so by listing every metric plus a last-activity timestamp. Source of projectId and the days window are covered by the schema, so an agent has everything needed to call and interpret 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?

Schema description coverage is 100%, so both parameters are already documented in the schema (days default 30, projectId sourced from findUserProjectsTool). The description only alludes to 'the last N days,' adding no syntax or format detail beyond the schema, 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?

The description names a specific verb+resource and then enumerates the exact metrics returned (members, open missions, missions in progress, resources, decisions, timers, finished missions, hours logged), which distinguishes it from getMissionStatsTool and getProjectDetailsTool without opening a 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 gives an explicit use case: 'Use it to judge whether a rikma is active before planning,' and an exclusion ('no per-member financial data'). It does not name a sibling alternative (e.g. getProjectDetailsTool) for the case where narrative detail is wanted, 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only the notion that the result is a 'structured list', without saying anything about the shape, size, pagination, or caching behavior of that list.

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 naming verb, resource, and scope, followed by a documentation pointer. Nothing is redundant and nothing buries the operative 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 no-parameter, read-only listing tool with no output schema, the description covers purpose and points to external docs. The only shortfall is that 'structured list' leaves the return shape unspecified, though annotations already handle the safety and side-effect questions.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level claims are made that could mislead an agent.

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 a structured list of available pages on the 1lev1.com site'), which is far more informative than the bare tool name. It does not, however, differentiate itself from the closely related sibling navigateToPageTool, so an agent cannot tell from the description alone which of the two 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?

'useful for navigation' implies a context of use, but it is a one-clause hint rather than an explicit when-to-use statement. There is no guidance on when-not to use it or how it relates to alternatives such as navigateToPageTool, searchCatalogTool, or searchContentTool.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: permission-dependent visibility (owner/proposer vs. public card) and the warning that proposal decisions cannot be made here but require opening a returned URL. It does not mention pagination or rate limits, keeping it at a 4.

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 verb and resource, followed by return contents, access scoping, and the accept/decline caveat in three efficient sentences. The trailing docs URL is minor overhead rather than filler, so it is not perfectly minimal.

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 read-only tool with no output schema, the description does the heavy lifting by describing what is returned (missions, resources, coverage, proposals) and the visibility rules. The reference to a returned URL implies response shape without fully specifying it, leaving a small gap.

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 (wishId) with 100% schema description coverage, and the schema already explains its origin (from listMyWishes or a /concierge or /wish URL). The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get one wish (concierge request)') and enumerates exactly what it returns: needs broken into missions and resources, coverage, and proposals. This clearly separates it from siblings like listMyWishesTool (plural list) and getMissionDetailsTool (different resource).

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 context for when the tool applies, including the access-scoped outcomes ('Full detail for the wish owner and for anyone who proposed on it; others see only the public card of an open wish'). It also excludes an adjacent action ('Accepting or declining a proposal is never done here'), but does not name a sibling tool alternative, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds behavior the annotations cannot express: result ordering ('newest first'), result granularity (one conversation per involved entity), and payload content ('with the last message'). It omits pagination behavior for the limit parameter, so it falls short of full transparency.

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

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

Front-loaded with the core action, then the scoping clause, then the usage cue and docs link; every sentence carries information. The enumeration of entity types is somewhat long but it defines the tool's granularity, so it earns its space.

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 responsibly covers what comes back (last message, newest-first ordering, one row per thread). The remaining gap is pagination/limit interaction, which an agent calling a list tool would benefit from knowing.

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%: limit already documents its default (25) and maximum, and projectId documents its meaning. The description adds no syntax or format detail beyond the schema (it doesn't even mention projectId), 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?

The description states a specific verb and resource ('List the conversations (forums) the caller takes part in') and pins down the scope that separates it from siblings: only threads the caller participates in, one per mission/act/decision/profit split/wish proposal. An agent can distinguish this from listMyWishesTool, listMyWishOffersTool and readConversationTool 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 gives a concrete trigger ('Use it to find the forumId of the thread a request is about'), which is a real workflow cue. It does not, however, name the alternative tools (readConversationTool, openRikmaConversationTool) or state when not to use it, so routing between the conversation siblings is only partially resolved.

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

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

Annotations already declare readOnly, idempotent, non-destructive and non-openWorld behavior, so the safety profile is covered. The description adds only the shape of the payload (status, coverage, counts), with nothing about ordering, pagination, or result limits for a list 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?

Two compact sentences that front-load what is listed and when to use it, followed by a docs link. No restatement of the title and 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 parameters, no output schema, and annotations covering the safety profile, the description supplies what an agent needs to select and call it. It stops short of describing result volume or ordering, which matters slightly for a list tool in a family of 40+ siblings.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter guidance because there is nothing to configure, and it does note the per-wish output fields.

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 the caller's own wishes'), and the parenthetical '(concierge requests)' plus the field list (status, coverage, mission/resource counts) makes the scope concrete. The 'caller's own' qualifier implicitly separates it from detail-oriented siblings like getWishDetailsTool, but no sibling is named 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 use case: answering 'what did I ask for' and selecting the wish a follow-up refers to, which usefully routes the agent toward this list tool rather than a detail tool. No explicit negative guidance or named alternatives, so it stops short of the top band.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real semantic context beyond that: the result is scoped to proposals where the caller is the proposer, and each entry carries a status. It says nothing about ordering, volume, or pagination, which is the only remaining 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?

Three short sentences, front-loaded with the scope, then the use case, then the exclusion, followed by a docs link. Nothing is padded, though the "concierge" framing costs a beat of parsing before the concrete meaning lands.

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

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

With no input parameters and no output schema, the description carries the burden of describing what comes back, and it does: what someone asked the caller to provide, what the caller offered, and the status. Combined with annotations, an agent has everything needed to call it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless schema applies. The description correctly implies no filtering input is available (the list is implicitly scoped to the caller).

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

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

The description names a specific verb+resource (list every proposal the caller is the proposer of) and pins the perspective: the supplier side, not the requester side. It also distinguishes itself from the responding flow (dismissOfferTool), so an agent can separate it from listMyWishesTool 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?

It gives a concrete use case in the user's own words ("who wants something from me") and an explicit exclusion ("Responding to one happens on its page, not here"), which steers the agent away from treating this as an action tool. It does not name the specific sibling tool that performs the response, so routing is implied rather than explicit.

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

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

Annotations already declare read-only, idempotent, non-destructive, and non-open-world behavior. The description adds valuable context beyond annotations: the members-only access requirement, the categories of resources returned, and a documentation link. It does not detail pagination or exact return shape, but the bar is lower given the annotations.

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

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

The description is front-loaded with what the tool lists, followed by usage, access constraint, and docs link. The first sentence is a dense enumeration that could be slightly tighter, 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?

For a simple one-parameter list tool with no output schema, the description supplies enough context: what it returns, when to use it, and the members-only restriction. Minor gaps like pagination or output format are not disqualifying given the tool's simplicity and annotation coverage.

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

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

Schema description coverage is 100%, and the single projectId parameter is documented in the schema as coming from findUserProjectsTool. The description adds no additional parameter meaning or syntax, 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 (List) and resource (rikma resources: links, in-progress resources, open resources, products), making the scope unambiguous. It also contrasts itself with suggestion behavior ('before suggesting one'), implicitly distinguishing it from proposeProjectLinkTool.

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 use case ('check whether a rikma already has a website/repo before suggesting one') and a prerequisite ('Members only'). It does not explicitly name alternatives or state when not to use this tool, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive flags. The description adds meaningful non-structured context: 'Members only' discloses an authorization requirement, and it enumerates what the return payload conceptually contains (conversation, open missions, resources, formed objects). It doesn't cover pagination, but the auth constraint and content shape are valuable additions beyond annotations.

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 purpose, followed by a gloss of what a 'process' means, usage guidance, and access constraint. The em-dash phrase defining 'processes' is slightly verbose but earns its place by disambiguating a domain-specific term. The trailing docs URL is short and useful.

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 read-only list tool with one fully documented parameter and annotations covering the safety profile, the description supplies everything needed: what it returns conceptually, when to call it, and who can call it. Only return-format/pagination details are absent, which is acceptable given the low 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 100% – projectId is fully documented in the schema as 'Rikma (project) id.' The description adds no syntax, format, or constraint details for the single parameter, so the baseline of 3 is appropriate when the schema does all the work.

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

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

Specific verb (List) plus resource (a rikma's processes) with a clarifying definition of what a 'process' is ('open-ended threads... an approach to a partner, a launch, a funding attempt'). This distinguishes it clearly from siblings like startProcessTool, attachToProcessTool, and listProjectResourcesTool.

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 when-to-use is given: 'Use it to see what is already in motion before starting something new.' This routes agents away from redundant creation calls and toward this reconnaissance tool, with no ambiguity about the trigger 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes nothing beyond that — no note on pagination, default limit behavior, or result ordering — so it adds no behavioral value over the structured fields.

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 sentence with the action front-loaded, followed by a documentation link. It is appropriately sized, though the trailing URL is slightly noisy.

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 five-parameter, zero-required listing tool with full schema coverage and covering annotations, the description is minimally adequate: the structured fields supply limits, filters, and safety semantics. It is not misleading, but it omits any mention of result shape or default-limit implications for an agent that needs to call it correctly.

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

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

Schema description coverage is 100% and every parameter (limit, filter enum, projectId, missionName, projectName) is documented in the schema itself. The phrase "various filtering options" adds no syntax, default, or matching-behavior detail beyond 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?

The description states a specific verb+resource ("List user missions") and mentions filtering, which is enough to understand the operation. However, it never distinguishes itself from close siblings such as getMemberMissionsTool or findMissionTool, leaving the agent to guess which listing tool is appropriate.

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?

"with various filtering options" is the only usage hint; there is no when-to-use, no prerequisite, and no named alternative among the many sibling list/find tools. An agent gets no routing guidance at all.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the tool performs no navigation itself and the return value carries the path to append to https://1lev1.com, which is exactly what an agent needs to know before calling it.

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 purpose and the key caveat, then parameters, then the sibling pointer and docs link. The semicolon-chained sentence is dense but every clause carries information; a small trim is possible but nothing 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?

For a no-output-schema, three-parameter link builder, the description covers purpose, non-side-effect behavior, parameter usage, result shape, and where to find valid inputs. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% (baseline 3), and the description goes further by giving concrete path examples ('/lev') and clarifying the relationship between url and idPr ('/moach/<projectId>' with idPr), which the schema alone does not spell out. It stops short of full format/validation detail.

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 ('turn a 1lev1.com page into a link') and immediately disambiguates scope with 'it does not open anything by itself'. An agent can tell this apart from siblings like getSitePagesTool or openRikmaConversationTool without opening a 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?

Explains the intent (produce a link to give the user) and points to the alternative for enumerating paths ('getSitePagesTool lists the valid paths'). No explicit when-not condition is given, but the operating context is clear enough to select correctly.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so mutation semantics are partly covered. The description adds genuinely new context: the thread is auto-created on first open (a side effect), and access is "Members only," which is an auth constraint not present in the annotations.

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 resource and its scope, then the usage rule, then the return contract. Mostly efficient, though the parenthetical "where it stays on record" is decorative and could be cut.

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 the get-or-create side effect, the members-only constraint, and the return value (forumId) despite there being no output schema, and links to docs. Complete enough for an agent to call it correctly; only the exact error/empty behavior is unstated.

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

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

Single parameter with 100% schema description coverage, so the schema already documents projectId as the rikma id. The description adds no syntax, format, or sourcing guidance beyond that, which matches the baseline 3 for a fully documented parameter.

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 resource (the rikma's own general conversation) with a clear scope boundary: the thread belonging to the whole rikma rather than to a mission, act or decision. An agent can distinguish it from siblings like listMyConversationsTool and readConversationTool without opening a schema.

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

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

Explicitly prescribes when to use it ("what are we doing next" talk) and when not to (anything about a specific mission, decision or profit split belongs in that thing's own thread). It also tells the agent what to do next with the result, naming readConversation and postConversationMessage as consumers of the returned forumId.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely non-obvious behavior: results are deduplicated against existing project content, nothing is persisted in the project, the return is a reviewUrl with per-row approval, and error.retryable signals whether a retry helps. These details go well beyond the annotations.

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 action and the createPlanBoardTool alternative are front-loaded, and each sentence (dedup, review flow, prerequisite, retry semantics, docs link) carries distinct information. It is on the longer side, but nothing is redundant.

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 still explains the return value (a reviewUrl for per-row approval), the deduplication behavior, the error contract, and the prerequisite tool. An agent has everything needed to call this 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 100%, so the schema already documents text, title, and projectId, and the description largely repeats this (projectId required, richer brief is better). The findUserProjectsTool hint for projectId adds slight value, but with the schema doing the heavy lifting 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?

The description states a specific verb and resource: 'Turn a free-text brief into a planning board' with the concrete outputs (proposed missions, chores/acts, resources). It explicitly distinguishes itself from the sibling createPlanBoardTool, so an agent can route correctly 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?

It gives explicit when-to-use ('the user describes something in loose words'), when-not-to-use ('if the conversation already holds a concrete breakdown... use createPlanBoardTool instead'), and a prerequisite (requires projectId, use findUserProjectsTool first if unknown). This is a complete routing 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?

Annotations already declare a non-read-only, non-destructive, non-idempotent write. The description adds genuinely new behavior: other participants are notified, and the message is visibly marked as written through an agent. It does not state what happens on failure or whether repeated posts duplicate, but the added side-effect disclosure is substantial.

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, then the notifications side effect, then the usage constraints, in three tight sentences with no filler. Slightly long, and the docs URL is a minor appendage, but every clause carries decision-relevant 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 two-parameter, non-destructive write with full schema coverage, the description covers purpose, side effects, and invocation boundaries. No output schema exists and none is needed for a post-only action.

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% for both parameters (forumId sourced from listMyConversations, message in the user's own words/language, plain text, 4000 max). The description echoes the 'in the user's own words and language' intent but adds no format or syntax beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Post a message, as the user, in a conversation (forum) they take part in') and grounds it with three concrete examples (mission update, decision thread answer, profit split note). It is immediately distinguishable from siblings like readConversationTool and openRikmaConversationTool.

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

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

Gives an explicit positive trigger ('ONLY when the user asked to say or record something') and two explicit exclusions ('never to think out loud', 'never to agree or refuse on their behalf'), plus the reason (approvals are the user's own click). This is the strongest form of routing guidance.

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

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

Annotations mark this as a non-readonly, non-destructive mutation but disclose nothing else. The description adds the crucial behavioral facts: nothing is created until the recipient acts, the user gets no access to the result, the call is refused when the email is the user's own, the link expires in 14 days, and previewUrl is publicly viewable. That is context the structured fields do not carry.

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: purpose, then the exclusion, then behavior and outputs. Nearly every sentence carries routing or behavioral information, with only mild redundancy around the intent/output mapping.

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 tool with a deeply nested blueprint object and no output schema, the description does the important work of naming the returned links (signupUrl, receiveUrl, previewUrl) and the conditions that produce them. It is close to complete, though it delegates blueprint structure entirely to prepareSignup rather than describing it here.

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 44%, and the description compensates for the required parameters by clarifying that name/email must be the other person's as the user gave them, and by explaining how intent/blueprint are reused verbatim from prepareSignup. However it leaves optional parameters (lang, wishText, aboutText, countries) and blueprint internals entirely unexplained, so the compensation is partial.

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 ('Prepare a rikma ... for ANOTHER person') and explicitly bounds the scope to someone other than the user. It names the sibling it is not (proposeRikmaBlueprint for the user's own business) and references prepareSignup as the format source, so an agent can distinguish it from neighbors without opening a 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 examples (new customer's business, helping another member start) and an explicit when-not-to-use rule ('NEVER use it for the user themselves ... use proposeRikmaBlueprint'). It also adds a gating instruction ('If it is not clear who the rikma is for, ask before calling'), which is strong routing guidance.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description adds genuinely new behavioral facts: nothing is created yet (status 'prepared' until publish), catalogue name uniqueness is reused automatically, never rename to force uniqueness, and the returned url must be passed through verbatim. That is well beyond what the annotations convey.

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 purpose and the primary routing rule, with dense but non-redundant sentences. It is on the long side and the catalogue-uniqueness passage is somewhat sprawling, but nearly every sentence carries operational 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?

There is no output schema, yet the description explains the return value (url, used as-is), the deferred-creation semantics, required inputs and the sibling tools to consult first. For an 8-param tool with rich annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and each parameter (roles, skills, valph, nhours, descrip, workways) is documented in the schema itself. The description only adds the projectId sourcing hint and the catalogue-matching nuance, 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?

Opens with a specific verb+resource ('Prepare the mission creation form') and states the concrete output (a pre-filled link). It goes further by defining what a mission is ('work that needs an implementer to be found'), which cleanly distinguishes it from createTaskTool and the get* inspection 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?

Explicit when-to-use ('when the user should review and confirm the mission before it is published'), explicit alternatives ('create a task (act) on it with createTaskTool instead'), and a prerequisite check ('Check the rikma's open missions (getProjectDetailsTool) first'). It also names findUserProjects as the way to obtain a missing projectId.

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

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

Annotations provide only safety profile bits (readOnly=false, destructive=false). The description adds substantial behavioral context: nothing is created until the user confirms, the agent cannot sign/set-password/confirm-email, signupUrl is valid 24h, previewUrl is returned for blueprint intents, and after email confirmation the user lands in the prepared state. This is well beyond what annotations disclose.

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 and when-to-use are front-loaded, which is good, but the body is a dense run-on of invented jargon ('rikma', '1lev1', 'rikmas') and nested parentheticals that make it hard to parse in one pass. Much of the volume is warranted, but the structure and terminology reduce readability.

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-param tool with nested objects and no output schema, the description is largely complete: it explains the return artifacts (signupUrl, previewUrl) and the user-side steps that gate creation. The uncovered 'lang' parameter and the referenced-but-not-described blueprint fields leave minor 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 only 38%, so the description must compensate, and it does for the critical paths: intent enum values are individually explained, and the conditional passing of blueprint/aboutText/wishText per intent is spelled out, along with the rule to pass only user-provided name/email. However, 'lang' is never addressed and the blueprint shape is only cross-referenced to proposeRikmaBlueprint rather than itemized.

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 ('Prepare a 1lev1 signup for a person who has NO 1lev1 account yet') and immediately distinguishes it from siblings by referencing proposeRikmaBlueprint. An agent can tell exactly what this tool creates and for whom 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?

It gives an explicit when-to-use condition ('only when the person's own request is what 1lev1 does'), an explicit when-not ('Do not bring it up in any other conversation'), and a required pre-call step (tell the person what will be sent and get their go-ahead). The intent values are laid out as routing alternatives with the condition that selects each.

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

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

Annotations only declare the generic mutation profile (readOnlyHint=false, idempotentHint=false). The description goes well beyond that: in multi-member rikmas, website and Facebook changes open a member vote where silence approves on clock expiry, while other links change directly. That voting/approval semantics is exactly the kind of non-obvious behavior 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?

Front-loads the action and target, then layers permission and voting behavior, ending with a docs link. Dense but every sentence carries information; the trailing docs URL is the only mild 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?

With no output schema, the description covers action, target, permissions, and the vote-vs-direct distinction well. It stops short of describing the response (e.g., whether a proposal id is returned when a vote opens), which an agent invoking a mutation tool would benefit from.

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

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

Schema description coverage is 100%, and the schema itself documents url (empty string clears), kind (enum), and projectId. The description adds nothing beyond what the schema already states, so the baseline of 3 applies.

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

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

States a specific verb pair (set or clear) and the exact resource (one of a rikma's named links), enumerating the link kinds. An agent can distinguish this from sibling tools like listProjectResourcesTool or createProjectTool immediately.

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

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

Gives explicit sequencing guidance ('Check listProjectResourcesTool first - the link may already be there') and a gate ('Members only'), plus the condition that triggers a vote. It stops short of stating when not to use the tool, but the routing context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds behavior annotations do not: messages are returned newest-last and each is attributed to its author, plus the participation restriction. It does not describe truncation or error behavior when the forum is inaccessible.

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 plus a docs link, with the purpose and return shape front-loaded ahead of the usage guidance. No filler or restated name/title content.

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, yet the description supplies the return shape (messages in order, with authors) and the intended use, which is enough for a two-parameter read tool. Minor omissions remain, such as whether it errors or returns empty for a forum the caller cannot access.

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 forumId (source: listMyConversations) and limit (most recent, default 30) documented in the schema itself. The description adds virtually nothing about the parameters beyond the ordering detail 'newest last', 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?

The description gives a specific verb and resource ('Read one conversation (forum)') and scopes it to conversations 'the caller takes part in', which separates it from listMyConversationsTool's plural listing. It also states the returned content (messages with authors, newest last). It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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?

'Use it before answering in a thread, so the reply fits what was already said' gives a concrete triggering condition, which is more than most read tools offer. It gives no exclusion or explicit alternative, though the schema's forumId note points at listMyConversationsTool as the source of the 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?

Annotations already cover the mutation profile (readOnlyHint=false, destructiveHint=false, not idempotent), so the description's added value is the key behavioral fact that a model interprets the free text rather than the caller naming ops. It omits what happens on failure or a version mismatch, so it stops short of full 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 tight sentences plus a docs link, with the differentiation from setAssistantItems front-loaded. Slightly dense with nested quotes, but nothing 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?

For a model-backed mutation with no output schema, the description covers what the tool does and when to use it but not the prerequisites (a session must already exist) or the meaning of expectedVersion. An agent can invoke it, but may not handle version conflicts or the assistant session lifecycle 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 0% across three required params. The quoted example ('that's right, drop the second, add photography') usefully conveys that instruction is natural-language text relative to a list, but sessionId and especially expectedVersion (an optimistic-concurrency token) are left completely 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?

States a specific verb and resource (change a list) with a concrete input example, and explicitly separates itself from setAssistantItems. An agent can tell the 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 rule: 'Prefer setAssistantItems when you can name the ops yourself; this one runs a model.' It names the alternative and the condition that selects it, which is exactly what usage guidance should do.

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?

Goes well beyond the annotations by scoping side effects precisely ('saved as suggested directions only: nothing is created, and no mission, chore or resource comes out of this call'), naming the returned reviewUrl as the approval surface, and disclosing failure semantics ('error.retryable' indicates whether a retry can help). This clarifies what the non-readOnly, non-idempotent hints actually mean in practice.

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 sentences, front-loaded with the core action and scope before the triggering conditions, side effects and failure handling. Dense and purposeful, though the docs URL and failure clause make it slightly longer than strictly necessary.

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

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

No output schema exists, and the description still names the key output artifact (reviewUrl) and the approval flow that consumes it, plus retryability on failure. It stops short of saying how many directions come back or what the failure payloads look like, but an agent has enough 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?

Only one parameter (projectId) and schema description coverage is 100%, so the schema already documents it fully. The description merely restates 'Requires a projectId' without adding format, sourcing or validation detail, which matches the baseline 3 for high-coverage schemas.

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 ('cheaply scan a project's real current state and propose DIRECTIONS') and explicitly narrows scope ('strategic angles, not task lists'), which separates it from siblings like planProjectWorkTool, createTaskTool and createPlanBoardTool that produce concrete work items.

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?

Names the triggering situation verbatim (open-ended 'what should we do next?' / 'how do we move this forward?' with no specific goal stated) and routes the follow-up work to a different path — opening the returned reviewUrl to break a direction into missions. Explicit when-to-use plus a named next step.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine access-scope disclosure ('Public data only') that the annotations do not state, which is useful context for an agent. It stops short of describing result ordering, empty-result behavior, or pagination.

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 resource scope before the usage note. The docs link is minor filler but not disruptive. Every sentence carries some information, though the trailing URL could be trimmed.

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 read-only, three-parameter search tool with a fully documented schema, the description covers what to search, when to reach for it, and the public-data constraint. With no output schema present, it could say more about the shape of results (grouped by kind, row limits), but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters (kinds, limit, query) are already documented in the schema, including the 'matched against names, descriptions and rikma names' semantics. The description adds nothing beyond that baseline, so a 3 is correct.

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 (search) and resource (the public catalog), then enumerates the three directories it covers: products for sale, open missions, and open resources. An agent can tell this apart from mutation-oriented siblings like createProjectTool or prepareMissionTool 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 guidance: 'Use it before opening a new wish or mission - somebody may already do this.' It also scopes usage with 'Public data only.' It does not, however, contrast itself with likely-overlapping siblings such as searchContentTool or findMissionTool, leaving that routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the meaningful access constraint that results are limited to rikmas the caller belongs to, but says nothing about result format, ranking, or pagination behavior beyond what the schema's limit parameter implies.

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 front-loaded sentences: scope and indexed content first, then the usage trigger with an example, then the sibling routing. The docs link is a useful pointer rather than filler, and no sentence is redundant.

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 read-only search with full schema coverage and complete annotations, nothing an agent needs is missing: purpose, scope, usage trigger, alternative tool, and a docs reference are all present. No output schema exists, so return-shape detail is not owed.

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 goes beyond the schema's terse "matched against names and descriptions" by enumerating the entity kinds whose names/descriptions are searched. That materially clarifies what the single query parameter actually matches.

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 (search) and scope (inside the rikmas the caller belongs to), then enumerates exactly what surfaces are indexed: rikma names/descriptions, missions, acts, resources, products. It explicitly distinguishes itself from the sibling searchCatalogTool, so an agent can route 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?

Gives an explicit when-to-use condition ("when the rikma is not known") with a concrete example query. It also names the alternative and its distinct condition ("For public listings of other rikmas use searchCatalogTool instead"), which is textbook alternative routing.

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

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

Annotations declare the mutation profile (readOnly false, destructive false, idempotent false, openWorld false), and the description adds genuine extra context: drop is reversible via restore, version conflicts surface as conflict:true, and failures return reason codes 'created'/'committed'. It does not describe auth requirements or the full shape of the returned list, but the disclosure goes well beyond the annotations.

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 and packed into a few dense sentences where each clause carries op semantics, conflict handling, or error routing. The run-on parenthetical style and domain jargon ('rikma') add reading cost, but there is little pure 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 5-param mutation tool with no output schema and low schema coverage, the description covers the important ground: op vocabulary, version/conflict handling, and terminal error reasons. It does not explain sessionId or enumerate the group values, and success return content is only alluded to ('show the returned list').

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 40%, so the description has to carry weight, and it does: it explains key ('refer to rows only by their key'), spec contents (price, keywords, hours), setField targets (rikma name, description), link (a product recipe), and expectedVersion ('pass the version you last saw'). sessionId and the group enum values are left to the schema, but the operation-bearing parameters are well covered.

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+resource ('change the draft list with small ops') and enumerates the eight operations, so the agent knows exactly what the tool mutates. It also implicitly separates the draft list from committed rows, which is what distinguishes it from applyAssistantTool, though no sibling is named 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?

It maps real user utterances to ops ("that is right"→keep, "not now"→drop) and gives an explicit negative case: rows already on the platform or a supplier-answered wish row cannot be changed here and the person should be sent to the site. The conflict path (pass expectedVersion, conflict:true means show the list and ask again) is also 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?

Adds substantial behavior beyond annotations: a 30-day validity window, that calling again replaces the old link, that revoke:true terminates it, that nothing is created, and that viewers need no account. These mutation/expiry semantics are exactly the kind of context annotations (readOnlyHint=false, idempotentHint=false) hint at but do not spell out.

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

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

Dense but front-loaded: the core action comes first, then scope, then lifecycle details. The parenthetical and em-dash clauses make it a long single run-on, which costs a little readability, but every clause carries real 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?

With no output schema, the description should ideally note what the agent receives back (e.g. the link/URL). It covers scope, lifecycle, and access model thoroughly, but that one return-value gap keeps it from full marks.

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 carry the load. It explains revoke:true (ends the link) well, but sessionId — the required parameter — is never explained as to which session/draft it refers to, leaving half the parameters 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?

States a specific verb+resource ('make a read-only link' showing a drafted rikma on 1lev1) and enumerates exactly what the preview contains: products, missions, resources, contributors, and share formation. This is clearly distinguishable from siblings like proposeRikmaBlueprintTool or listRikmaProcessesTool.

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 context for when to reach for it — to hand a preview to partners, with no account required to view. It does not name an explicit alternative tool or state when NOT to use it, so it stops 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?

Annotations declare it is not read-only and not destructive, so the write nature is known. The description adds meaningful context that this seeds from 'what is on it now' and returns rows with keys, which annotations don't convey. But it does not state whether starting overwrites existing list contents, whether it can be called repeatedly, or the auth/ownership requirements.

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 but front-loaded: the core purpose opens the sentence, then branches into (a) and (b), then the follow-up flow. Some nested parentheticals make it slightly heavy, 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?

Covers both usage branches, the follow-up editing/saving workflow, an exclusion to a sibling tool, and a docs link. Given the complex multi-step domain and no output schema, it provides an agent enough to call correctly, though it omits return-shape detail and ownership/permission context.

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

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

Schema coverage is 0%, so the description must compensate. It explains that text is 'what they told you' and ratsonId comes from listMyWishesTool, and that kind selects profile vs wish. However it never maps ratsonId is only for wish, nor clarifies that text can seed either kind, leaving some ambiguity about parameter combinations.

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: 'Open the person's living list' of a PROFILE or WISH, with the two kinds clearly distinguished. It does not name what a 'living list' or 'rikma' means in domain terms, but the two branch types are concrete enough for an agent to act.

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 guidance for each branch (pass text vs ratsonId) and names the follow-up tools (setAssistantItems, reviseAssistant, applyAssistant). It also states an exclusion: 'A rikma is not started here: use proposeRikmaBlueprint.' Lacks explicit preconditions (e.g., must a profile already exist to seed from?).

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

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

Annotations cover the safety profile (non-read-only, non-destructive, non-idempotent, closed-world), so the bar is lower. The description adds real context beyond them: the description field becomes the first message (a side effect), and the operation is restricted to members (an auth requirement). It does not describe the returned object, though no output schema exists.

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 carries content (definition, lifecycle, member restriction, usage rule). It is slightly long and the 'take shape later' phrasing is a touch indirect, but nothing 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?

For a non-idempotent creation tool with full schema coverage, no output schema, and annotations already declaring the safety profile, the description supplies the remaining essentials: what the entity is, what gets created as a side effect, who may call it, and how the lifecycle continues into attached missions/resources.

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 earns extra credit by explaining the semantic role of the `description` parameter ('becomes the first message ... can be written in plain words') — meaning the schema itself does not convey. It does not clarify `name` beyond the schema's own example.

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+resource ('Start a process in a rikma') and then defines what a process actually is ('a named thread with its own conversation'). It explicitly distinguishes it from the siblings it could be confused with — 'something that is not yet a mission or a resource' — so an agent can separate it from prepareMissionTool/createTaskTool/createProjectTool.

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 ('when the user wants to record something the rikma is pursuing') and an explicit exclusion ('not to file your own notes'), plus a prerequisite constraint ('Members only'). It also routes the later-stage workflow to the named sibling attachToProcess, so alternatives 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?

Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the safety profile. The description adds that multiple actions are supported but does not disclose side effects, reversibility, or permission requirements. With annotations doing the heavy lifting, a 3 is appropriate.

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?

Single, front-loaded sentence with no wasted words. The docs link is appended efficiently. It is appropriately sized for a simple action tool, though it could be slightly more informative without sacrificing 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?

The tool is a mutation with no output schema, and the description is minimal. It does not explain what happens on start/stop/pause/resume or how the missionId interacts with active timer discovery. For a non-idempotent action tool, this leaves some 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 100%, and the schema already documents both parameters including the enum values and the optional missionId behavior. The description adds no additional meaning beyond what the schema provides, 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 ('Perform actions') and resource ('user timers') with the full action set enumerated. It is clear, though it does not differentiate itself from siblings like getActiveTimersTool or applyAssistantTool, 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 guidance on when to use this tool versus alternatives. It does not mention getActiveTimersTool for finding timers, nor does it explain when each action is appropriate. The only hint is an external docs link, which is not inline guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and closed-world scope, so the safety profile is covered structurally. The description adds genuinely useful scope context — that the undone change may have originated from the site, not just this session — but says nothing about the version-conflict behavior implied by expectedVersion or what happens on repeated calls given non-idempotency.

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 verb and target up front, plus a docs link; no filler. Slightly compact given the undocumented parameters, but nothing 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?

For a mutation tool with two required, fully undocumented parameters and no output schema, the description omits precondition/failure behavior and return semantics. The only substantive detail added is the cross-context scope of the undo, leaving an agent unable to call it confidently against a version guard.

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 two required parameters, and the description mentions neither sessionId nor expectedVersion. expectedVersion in particular carries concurrency semantics (it likely guards against undoing the wrong revision) that the agent cannot infer from the bare 'integer' type, so the description 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 and resource ('Undo the last change to the draft list') and scopes it to the most recent change only, which distinguishes it from the sibling applyAssistantTool/reviseAssistantTool pair that make forward changes. It does not explicitly name a sibling or contrast with a redo/version-history tool, so it falls short of full differentiation.

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 last change' implies a single-step, most-recent-only undo rather than an arbitrary rollback, and '(from here or from the site)' signals it spans changes made outside this session. However, there is no explicit guidance on when to prefer this over applyAssistantTool/reviseAssistantTool or on failure/precondition handling.

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