argo-mcp

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, signaling a non-destructive but state-changing operation. The description does not add extra behavioral context such as whether acceptance is reversible or triggers notifications. It does not contradict the annotations, but it also adds little beyond the obvious effect.

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, clear sentence that front-loads the key verb and resource. No redundant phrases or filler—every word earns its place.

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

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

For a simple one-parameter action with full schema coverage and an output schema, the description is complete enough. It could mention return behavior or side effects, but the structured fields already cover the output, and the action itself is straightforward. Loses one point because a note about the necessity of an existing incoming request would improve contextual 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% (userId described as 'Argo user ID of the counterparty'). The description's 'given user' aligns with this but adds no new semantic detail. Since the schema adequately explains the parameter, a baseline of 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 uses the specific verb 'Accept' with a clear resource 'incoming friend request', which precisely distinguishes it from sibling tools like send_friend_request, cancel_friend_request, and reject_friend_request. The phrase 'from the given user' further clarifies the action is on a specific incoming request.

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

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

The phrase 'incoming friend request' implies the tool is for accepting requests you received, contrasting with sending or canceling your own. However, the description does not explicitly state when to use this tool versus alternatives like reject_friend_request, nor does it mention any prerequisites (e.g., the request must exist).

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?

The description discloses authorization requirements (active membership and GM status enforced server-side), going beyond the annotations. It provides useful behavioral context without contradicting the settings.

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 exactly two sentences long, front-loaded with the action, and the second sentence adds necessary constraint information without redundancy.

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

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

With a simple tool, full parameter documentation, and an output schema available, the description covers the essential purpose and usage constraints. No additional behavioral details are needed.

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

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

The schema fully describes both parameters ('Guild ID' and 'Campaign ID to add to the guild'), so the description adds no parameter-specific meaning. Baseline of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the action: 'Add a campaign to a guild' with a specific verb and resource. It is unambiguous and easily distinguished from sibling tools like add_co_gm or add_guild_calendar_event.

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 provides clear guidance on who can use the tool: any active guild member, with the calling user required to be the campaign's GM. This gives context for use, though it does not explicitly mention alternatives or when not to use it.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behaviors: the offer-based flow, the acceptance requirement, the owner-only restriction, and the limit of 5 co-GMs. These are essential for the agent to understand the tool's side effects and constraints.

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 concise sentences deliver the core purpose, a critical caveat, and two constraints. Every sentence earns its place with no redundancy or filler.

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

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

For a simple offer-sending tool, the description covers all behavioral requirements: the offer mechanism, the need for acceptance, the owner-only rule, and the cap. An output schema exists, so return value details are not the description's responsibility. The description is complete for the tool's complexity.

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

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

The input schema already documents both parameters with 100% coverage, so the description does not need to elaborate. The mention of 'user' and 'campaign' aligns with the schema but adds no additional parameter-level semantics beyond what the schema provides.

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

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

The description clearly states 'Send a user an assistant GM (co-GM) offer for a campaign,' providing a specific verb and resource. It also distinguishes itself from sibling tools by explicitly noting it does NOT add immediately, which prevents confusion with any direct-add interpretation.

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

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

The description gives explicit usage guidance: it clarifies that the target must accept the offer, so it is not for immediate addition. It also specifies an owner-only precondition and a maximum cap of 5 co-GMs, giving clear conditions for when this tool is appropriate.

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 indicate a non-read-only, non-destructive operation, and the description adds valuable behavioral context: the Owner/Admin permission requirement and the ISO-8601 format for date-time parameters. This goes beyond the annotation defaults.

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

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

Two sentences, front-loaded with the core action, then essential constraints. No fluff or redundancy; every sentence contributes meaningful 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?

Given the output schema exists (so return values need not be described), the description covers the core action, permissions, and date format. It does not discuss error cases or side effects, but for a relatively simple add-operation with annotations and schema, it is sufficiently complete.

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% since all five parameters have descriptions. The description's note about ISO-8601 repeats what the schema already states, adding no new semantic meaning beyond the structured fields. Baseline of 3 is appropriate.

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

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

The description clearly states 'Add a new event to the guild's shared calendar' with a specific verb and resource, distinguishing it from sibling tools focused on other entities like campaigns or mnemons. The 'guild calendar event' scope is unambiguous.

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

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

It provides clear context by noting 'Owner/Admin only', which indicates when this tool can be used. It does not explicitly mention exclusions or alternatives, but the resource specificity and permission hint give adequate usage guidance.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds important context: it only applies to requests the caller sent, implying the request must still be pending. This goes beyond what annotations convey without contradicting them.

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 that conveys the action, resource, and scope. No redundant words or repetition of the title or 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?

This is a simple, single-parameter tool with an output schema and adequate annotations. The description, together with the schema and annotations, fully covers what the tool does and its precondition (previously sent request). No significant information gaps remain.

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

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

The schema already provides 100% coverage with a clear description for userId ('Argo user ID of the counterparty'). The tool description does not add parameter-specific syntax or constraints beyond implying the request must exist, which is contextual rather than a semantic enrichment of the parameter itself.

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

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

The description uses a specific verb 'cancel' with the resource 'friend request' and adds the critical qualifier 'you previously sent,' which clearly distinguishes this from accept_friend_request and reject_friend_request for incoming requests. This leaves no ambiguity about the tool's function.

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

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

The phrase 'you previously sent' provides clear context that this tool is for outgoing requests, implicitly contrasting with accept/reject for incoming ones. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full 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?

The description adds an authorization requirement (GM/co-GM only) beyond the annotations, which are all false hints. It does not disclose other behavioral traits like side effects or idempotency, but the annotations do not contradict the description.

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

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

The description is a single sentence that efficiently communicates the action, the resource type, and the access restriction without any extraneous detail.

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

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

The description covers the core purpose and access restriction, and the output schema exists to handle return values. However, it lacks explicit differentiation from sibling create_*_mnemons tools and provides no parameter guidance, leaving moderate gaps for an agent.

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 description does not mention the campaignId or items parameters. With 0% schema description coverage at the tool level, the description should compensate for parameter semantics, but it provides none, leaving the agent to infer from the schema.

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

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

The description uses a specific verb and resource: 'Create Archive mnemons' and defines them as 'archived lore that is no longer current.' This clearly identifies the tool's purpose and distinguishes it from other mnemon creation tools, though it does not explicitly name 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?

The description states that 'Players may not call this — GM/co-GM only,' providing an access restriction. It implies usage for archived lore through 'no longer current,' but does not explicitly contrast this with create_lore_mnemons or other sibling tools.

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

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

The description goes well beyond the minimal annotations by disclosing the OAuth scope requirement, the current user becoming GM, and the calling token gaining read+write access immediately without re-consent. These are concrete behavioral traits not captured by readOnlyHint/destructiveHint false values.

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 only two sentences but packs in the core action, side effects, access implications, and a prerequisite. Every sentence is informative with no fluff, and the key verb+object is front-loaded.

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

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

For a create tool with an output schema and 100% parameter description coverage, the description covers the critical contextual aspects: ownership, permission changes, and required OAuth scope. It does not need to explain return values due to the output schema, and it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the input schema already explains all four parameters with per-property descriptions. The tool description adds no information about the parameters, leaving the schema to carry the burden, which is acceptable per 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?

The description opens with 'Create a new Argo campaign,' using a specific verb and resource. It is clearly distinct from sibling tools like create_session or update_campaign, and the immediate consequences (becoming GM, token access) reinforce the unique purpose of this tool.

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

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

The description implies use for initial campaign creation and states a prerequisite ('Requires the campaign.create OAuth scope'), but it does not explicitly mention when not to use it or compare it to update_campaign. There is clear context without explicit alternatives or exclusions.

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

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

Annotations indicate a write operation (readOnlyHint=false) and no destructive intent (destructiveHint=false). The description adds the GM/co-GM permission restriction, which is valuable, but does not disclose bulk creation via the items array or any post-creation effects. The added context is helpful but not comprehensive.

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

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

The description is two concise sentences, delivering purpose and access restriction with no filler. Front-loaded with the primary 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?

Given the nested schema and output schema, the description provides enough for tool selection but omits practical details like bulk creation support (items maxItems) and optional fields (tags, customType, visibility). However, these are available in the schema, so the description is minimally 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?

The top-level parameters (campaignId, items) have no descriptions in the schema (0% coverage), and the description provides no parameter-level guidance. The description does not explain the structure of items or the meaning of customType, leaving the agent to infer from nested 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?

The description clearly states the action ('Create'), the resource ('custom-typed mnemons'), and the scope ('any free-form entry that doesn't fit the other types'), effectively distinguishing it from sibling create_*_mnemons tools.

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

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

It explicitly indicates when to use this tool ('any free-form entry that doesn't fit the other types') and restricts usage to GM/co-GM, but doesn't name specific alternative tools. This provides adequate situational 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 are all false, so the description must clarify safety/mutation. The description does add the important behavioral fact that only GMs/co-GMs may call this tool. However, it does not disclose batch behavior, validation, partial-failure handling, or any side effects beyond creation, leaving notable gaps in behavioral transparency.

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

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

The description is a single, tightly written sentence that conveys the core purpose and a critical access restriction. No filler or redundant information; every clause carries meaning.

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 functionally rich (batch creation, many optional fields, nested objects, permissions) but the description only covers purpose and permission. With an output schema present, return details are not required, but the lack of usage guidance and parameter insight makes the description incomplete for safe and correct invocation.

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

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

Context reports schema description coverage at 0% for top-level parameters. The description provides no explanation of campaignId or items, and does not help the agent understand the nested structure or required fields. Even though some nested fields (title, markdown) have descriptions, the description itself adds zero parameter semantics, so it fails to compensate for the schema gap.

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

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

Description states a specific action ('Create Journal mnemons') and clarifies what journal mnemons are ('log of in-world events'), which helps distinguish from sibling mnemon types. However, it does not explicitly contrast with sibling create tools like create_lore_mnemons or create_session_summary_mnemons, 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?

The only usage guidance is a permission restriction ('Players may not call this — GM/co-GM only.'). It does not explain when to use journal mnemons over other mnemon types, nor when to use create vs update_journal_mnemons. No alternatives are mentioned, so the agent has no context for tool selection beyond 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 only indicate readOnlyHint=false and destructiveHint=false, leaving the description to add auth and usage context. The description discloses the GM/co-GM restriction and the sequential dependency on create_mnemon_relationship, which are valuable 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?

Two sentences, front-loaded with purpose, and each sentence earns its place: the first defines scope, the second adds critical nesting and permission context. No redundancy or filler.

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

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

Given the tool's complexity and the presence of an output schema, the description adequately covers purpose, permission, and setup steps. It lacks parameter-level guidance, but the schema itself includes descriptions for some properties (title, markdown, levelId, visibility). The missing items/campaignId clarity is a minor 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it provides none. It doesn't explain campaignId or the items array structure, nor does it mention required fields. The description adds zero value for parameter understanding beyond the raw schema.

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

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

The description clearly states the tool's purpose: 'Create Location mnemons (places — cities, dungeons, taverns)'. The verb 'Create' plus the resource 'Location mnemons' and illustrative examples (cities, dungeons, taverns) make it distinct from sibling create_*_mnemons 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?

Provides specific after-creation guidance: 'Use create_mnemon_relationship with PARENT_OF to nest larger places under one another after creation.' It also specifies authorization: 'GM/co-GM only'. However, it doesn't explicitly state when not to use this tool versus other mnemonic types, though the title and examples make this 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 only provide readOnlyHint: false and destructiveHint: false, so the description carries the burden of behavioral context. It adds the key access restriction ('Players may not call this — GM/co-GM only') and scope (world background, factions, history). No contradiction with annotations. It does not detail side effects or rate limits, but the GM-only note is significant.

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 one sentence, front-loaded with the action and object, and includes only essential information (what it creates, who can call it). No fluff or redundancy.

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

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

The description is adequate for a simple creation tool with a schema, but it omits the batch nature (items array, max 50) and does not explain how this relates to other mnemonic types. Given the large sibling list and the existence of an output schema, more context about the item format or usage scenarios would improve 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 0%, so the description should compensate, but it provides no parameter details. The parameter names (campaignId, items) are partially self-explanatory, but 'items' remains vague without the schema's inner structure. The description does not clarify that items is an array of mnemonic objects, leaving the agent to rely solely on the schema's property names.

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

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

The description clearly states the tool creates 'Lore mnemons' and specifies content categories (world background, factions' beliefs, history). It distinguishes from sibling tools (e.g., create_archive_mnemons, create_custom_mnemons) by naming the lore type. The GM/co-GM restriction further clarifies the intended audience.

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 clear context that this is for lore-related mnemonics and is restricted to GM/co-GM, effectively saying who may call it. It does not explicitly name alternative tools or when not to use it, but the content examples imply when it is appropriate. A clear exclusion (e.g., 'for player-facing use, use create_custom_mnemons') would push it to 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 indicate a write operation (readOnlyHint false) and non-destructive behavior (destructiveHint false). The description adds valuable behavioral details about directionality (sourceEntryId as 'from', targetEntryId as 'to', bidirectional vs. directional labels) that go beyond the annotations. It doesn't discuss edge cases like duplicate relationships or idempotency, but the disclosure is strong.

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 information-dense; the opening sentence states the core purpose, followed by a comprehensive list of labels and their semantics. While it reads as a dense block of text, every sentence carries significant information, and the front-loading of the primary purpose is effective.

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

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

For a tool with 14 semantically complex labels and directional rules, the description is remarkably complete. It covers all label meanings, direction conventions, the inverse relationship between CONTAINS and LOCATED_IN, and cross-references the type matrix tool. With an output schema present, omitting return-value details is 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 0%, so the description must compensate. It adds clear meaning for sourceEntryId and targetEntryId (the 'from' and 'to' sides) and enumerates the allowed label enum values. However, it does not clarify the 'direction' parameter (which is a free-form string in the schema) or the purpose of 'color' and 'campaignId', leaving some parameters underspecified.

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

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

The description uses the specific verb 'Create' and identifies the resource as a 'relationship between two mnemon entries,' clearly distinguishing it from siblings like delete_mnemon_relationship and list_mnemon_relationships. It also provides the full taxonomy of relationship labels, making the tool's purpose unmistakable.

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

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

Explicitly provides when-to-use guidance by directing users to prefer array fields on NPCs and quests for faction and quest links, and states that SESSION_* labels are the only way to set session-summary links. It also directs users to call describe_mnemon_types for the full valid matrix, giving clear alternatives and exclusions.

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

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

The description adds valuable behavioral context beyond annotations: it discloses the server-side projection into MEMBER relationships and the GM/co-GM authorization requirement. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with a create operation, so there is no contradiction.

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 concise and front-loaded: first sentence states the core purpose, followed by key usage details and a permission note. Every sentence earns its place without fluff or repetition.

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

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

Given the detailed input schema and presence of an output schema, the description covers all essential operational context: purpose, type-specific requirements, membership wiring, and authorization. It leaves nothing critical unexplained for selecting and invoking the 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?

The description clarifies how memberNpcEntryIds and affiliationEntryIds relate to npcType and that they trigger server-side MEMBER relationship projection, adding semantic meaning beyond the raw schema. However, the schema already provides per-field descriptions, and the 'npcType is REQUIRED' note redundantly restates the schema's required array.

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

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

The description uses the specific verb 'Create' with the resource 'NPC mnemons' and explicitly enumerates the two types (FACTION or INDIVIDUAL), making the tool's scope immediately clear. It also distinguishes itself from sibling mnemons creation tools by focusing on NPC-specific entities.

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 states when to use the tool (creating NPC mnemons), clarifies type-specific membership wiring, and provides a clear permission exclusion ('Players may not call this — GM/co-GM only'). It does not explicitly name alternative tools for non-NPC mnemons, but the context is sufficient for an agent to select it appropriately.

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 indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral details: the auto-detach consequence when required fields are omitted, and the permission boundary. This goes beyond the minimal annotation disclosure.

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

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

The description is compact—three sentences, each containing essential information. The first sentence states the core purpose, the second gives conditional parameter guidance, and the third covers permissions. No filler or redundant 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?

Given the tool's complexity (multiple playerKind values, required parent/party/character IDs, permission nuances) and the presence of an output schema, the description sufficiently addresses the main complexities. It could mention the enum values for playerKind/visibility, but these are already in the schema. Overall, it provides enough context for correct use.

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?

Although the schema description coverage is listed as 0%, the actual schema includes descriptions for several parameters (partyId, markdown, characterId, parentEntryId). The tool description further clarifies the conditional semantics of parentEntryId, partyId, and characterId for playerKind=CHARACTER, adding meaning beyond the schema's field-level descriptions.

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

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

The description uses a specific verb 'Create' and clearly identifies the resource 'Player mnemons', enumerating the distinct types (party root, character notes, party notes). It differentiates this tool from sibling create_*_mnemons tools by focusing on 'player' mnemons.

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

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

The description provides clear conditions for when to use the tool, especially for playerKind=CHARACTER, listing required fields and the auto-detachment behavior. It also specifies permission requirements (players with campaign.write vs GMs). It doesn't explicitly mention alternatives, but the context and field conditions offer solid usage guidance.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with 'Create.' The description adds meaningful auth context (GM/co-GM only) not present in annotations, and there is no contradiction with the structured data.

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

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

The description is two short sentences, front-loaded with the action ('Create Quest mnemons'). No filler or redundant detail—every word 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?

The tool has a complex nested schema (items with steps, rewards, etc.) and two required parameters, but the description is sparse. It covers purpose and permission but omits any guidance on the items structure or campaign context. The rich schema and output schema compensate partially, yet the description feels incomplete for such a complex 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?

The description mentions 'questStatus is one of active|completed|failed,' but this exactly duplicates the schema's existing description for that property, adding no new semantics. Top-level parameters campaignId and items are not explained in the description, and schema coverage is 0%, so the description fails to compensate.

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

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

The description clearly states the tool's function with a specific verb ('Create') and resource ('Quest mnemons'). This distinguishes it from sibling tools like create_npc_mnemons or create_lore_mnemons, making the purpose unambiguous.

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

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

The description provides an explicit permission boundary: 'Players may not call this — GM/co-GM only.' This is a clear usage exclusion, though it doesn't elaborate on when to prefer this over other create tools, which is largely self-evident from the resource type.

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 indicate a non-read-only operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false), covering the mutation safety profile. The description adds some parameter behavior (endAt optional) but does not disclose broader side effects like invitations or scheduling conflicts. This meets the baseline for annotation-covered tools without contradiction.

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

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

The description is two concise sentences, front-loading the core action and then supplying the key parameter constraint. No redundant language or unnecessary details.

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

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

For a tool with six parameters (three required), a fully documented schema, and an output schema, the description adequately covers the creation use case. It lacks some behavioral context like invite side effects, but the structured data fills most gaps. Given the tool's complexity, this is sufficient.

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

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

The input schema has 100% coverage with descriptions for all six parameters, including ISO-8601 format and allowed invited members. The description's mention of 'Provide an ISO-8601 startAt; endAt is optional' adds no new information beyond the schema. Baseline score of 3 applies.

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

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

The description clearly states 'Schedule a campaign session' with a specific verb and resource, distinguishing it from siblings like update_session, list_sessions, and get_session. It also mentions the optional endAt and use cases for planned arcs or recurring play nights, adding further specificity.

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

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

The description provides usage context ('useful for laying out planned arcs or recurring play nights') and indicates that startAt is required while endAt is optional. However, it does not explicitly mention alternatives like update_session for modifying sessions, so it lacks explicit exclusions. Overall it gives clear context but 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 indicate a write operation (readOnlyHint=false) and non-destructive intent, which the description aligns with. Beyond annotations, it discloses an access control requirement (GM/co-GM only), which is valuable behavioral context not present in the annotations. It doesn't describe side effects or output formats, but for a create tool this is acceptable 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 a single, front-loaded sentence with no filler. It conveys the core purpose and a critical access restriction in just 13 words, making it exceptionally concise and well-structured.

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

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

The tool has a complex input schema with a nested array of up to 50 items and many optional fields, but the description provides only a high-level purpose and access rule. It doesn't explain the overall payload structure or the intent of each field, and the schema itself does not describe top-level parameters. The description is insufficient for an agent to use the tool effectively without additional inference.

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 description contains no information about the parameters (campaignId, items) or their meanings. With schema description coverage at 0% for top-level parameters, the description does nothing to explain how to construct a valid request, leaving the agent reliant entirely on the raw schema structure.

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

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

The description specifies a clear action ('Create') and a specific resource ('SessionSummary mnemons'), further clarified as 'structured summaries of game sessions.' This distinguishes it from sibling tools like create_archive_mnemons or create_quest_mnemons, and the GM-only restriction adds precise scope.

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 clearly states who may use the tool ('GM/co-GM only') and implies that players should not call it, providing a strong contextual guideline. However, it does not explicitly mention when to use this over update_session_summary_mnemons or other create_*_mnemons tools, leaving some room for interpretation.

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 mark destructiveHint=true, but the description goes beyond by disclosing permanence ('cannot be undone'), cascade effects ('every relationship that touches it'), and the requirement to confirm with the user. These behavioral traits are not visible in the annotations or schema, making the description highly transparent.

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

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

The description is two compact sentences that front-load the purpose and then deliver the essential constraints (permanence, GM-only, confirmation, entryId format). Every clause earns its place; there is no filler or redundancy.

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

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

For a destructive delete operation, the description covers what is deleted, side effects on relationships, irreversibility, access control, the confirmation step, and parameter formats. An output schema exists, so return values are not needed here. Given the tool's complexity, this description is fully adequate.

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

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

Schema description coverage is 100%: both parameters have descriptions, and entryId's 'hex or exact title' is already present in the schema. The description repeats this same detail without adding new semantics. CampaignId is not mentioned in the prose, but the schema covers it. Therefore, the description adds no significant meaning beyond the schema, fitting the baseline of 3.

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

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

The description opens with 'Permanently delete a mnemon entry and every relationship that touches it,' which gives a specific verb (delete), resource (mnemon entry), and scope (plus all relationships). This clearly distinguishes it from sibling tools like delete_mnemon_relationship, which only removes a single relationship.

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 includes critical usage guidance: 'GM-only on the backend' and 'confirm with the user before calling.' It clearly implies this is for whole-entry deletion, but it does not explicitly name an alternative for removing only a relationship (e.g., delete_mnemon_relationship). With that explicit sibling distinction absent, 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?

The description adds no behavioral context beyond the destructiveHint annotation. It doesn't mention irreversibility, permissions, or cascading effects.

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

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

A single sentence with no filler, efficient for a simple delete operation.

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?

Although simple, the tool requires two IDs and lacks explanation of their relationship or deletion scope. No usage guidance or parameter semantics, making it incomplete for an agent.

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?

With 0% schema description coverage, the description needed to clarify the roles of campaignId and relationshipId, but only says 'by id' ambiguously, failing to distinguish which ID is which.

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

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

The description uses the specific verb 'Delete' with the resource 'relationship' and specifies 'by id', clearly distinguishing it from sibling tools like create_mnemon_relationship and list_mnemon_relationships.

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 is provided on when to use this tool, prerequisites, or alternatives. It is a bare statement of action with no context.

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 and destructiveHint=false, so the safety profile is established. The description adds the domain constraint 'NPC subtype is strictly FACTION | INDIVIDUAL', which is useful context for selecting types, though not purely behavioral. This extra context earns 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?

Three sentences, each purposeful: the first defines the return content, the second gives usage guidance, and the third provides a critical domain constraint. No redundant or filler text.

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

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

Given zero parameters, an output schema, and annotations, the description fully covers purpose, usage timing, and a key subtype restriction. It is complete for a read-only catalog/reference 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?

The tool has zero parameters, so there is nothing to explain beyond the input schema. The description adds value by describing what the output contains, which is relevant but not parameter semantics. Baseline for 0 params is 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?

The description clearly states the tool returns a catalog of all mnemon types, their type-specific fields, and the relationship matrix. The verb 'Returns' and specific resource 'mnemon types' with details distinguish it from sibling creation 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?

Explicitly states when to use: 'Call this before create_mnemon or create_mnemon_relationship when you are unsure which type or label to use.' This gives clear context and names the alternative tools it supports.

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 openWorldHint=true, indicating a write operation. The description adds useful behavioral context by mandating duplicate checks and category lookup, which is not encoded in the 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?

The description is two sentences long: first states the core purpose and variants, second provides workflow prerequisites. No wasted words, front-loaded with the primary 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 simple creation tool with full schema coverage, annotations, and an output schema, the description fully covers prerequisites and purpose. No additional return-value or error-handling detail is needed.

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

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

The schema covers 100% of parameters with descriptive text (e.g., 'Topic body in Markdown', 'Call forum_list_categories first'). The tool description adds no new parameter-level detail beyond reinforcing the categoryId prerequisite, so it meets the baseline but does not exceed it.

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

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

The description clearly states the verb 'create' and the resource 'forum topic', and explicitly lists the topic types (bug report, feature request, general discussion). This distinguishes it from siblings like forum_reply and forum_search.

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

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

The description provides explicit instructions: 'Always call forum_search first to check for duplicates' and 'Call forum_list_categories to get the correct categoryId'. This clearly tells the agent when and how to prepare for the call.

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, covering the safety profile. The description adds the behavioral nuance of 'active' topics but does not disclose details like pagination or ordering. Since an output schema exists, return format is covered elsewhere.

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

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

The description is a single concise sentence, front-loaded with the key verb and resource. It contains no filler and is easy to parse at a glance.

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 no-parameter read-only tool with an output schema, the description fully captures the necessary context. The scope is clear, and the output schema provides return-value details, so no additional explanation is needed.

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

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

The tool has zero parameters, and the schema coverage is 100% with an empty object. Per guidelines, a baseline of 4 is appropriate since the description is not required to explain parameters that don't exist.

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

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

The description states the tool's function with a specific verb ('Get'), resource ('latest active topics'), and scope ('across all forum categories'). This clearly distinguishes it from sibling tools like forum_list_topics, which likely lists all topics without the 'active' filter.

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

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

The description implies when to use this tool (when the user needs the latest active topics across all categories), but it does not explicitly contrast it with alternatives such as forum_list_topics or forum_search. There is no when-not-to-use guidance, but the context is clear enough for basic selection.

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 state readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the specific content categories (replies, mentions, likes) and clarifies the scope to the current user, which is useful context 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?

One sentence, 10 words, front-loaded with the purpose, no wasted text.

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 simple, has no parameters, and has an output schema. The description covers the key points: whose notifications and what types. Nothing essential 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?

The tool has zero parameters, so the schema is trivially 100% covered. The description implies no input is needed. According to the rubric, 0 params gets a baseline of 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?

The description uses the specific verb 'Get' and names the resource 'forum notifications' for the current user, with types in parentheses. This clearly distinguishes it from sibling forum tools like forum_get_user_posts and forum_get_latest_topics.

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?

Clear context is provided: it is for retrieving the current user's notifications. However, it does not explicitly state when to prefer this over alternatives or when not to use it, 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, and destructiveHint, covering the safety profile. The description adds only the current-user scoping, which is a semantic constraint rather than a behavioral disclosure. It does not contradict annotations but provides minimal additional behavioral context.

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

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

The description is a single concise sentence that directly states the action and scope. It is front-loaded and contains zero unnecessary words, earning a maximum score for conciseness.

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

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

With no parameters and an existing output schema, the description sufficiently conveys the tool's purpose and scope for a simple read-only operation. It does not explicitly differentiate from sibling tools, but its clarity compensates given the tool's simplicity.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuous). With 0 params, the baseline is 4, and the description correctly does not need to explain any parameter semantics. It is consistent with the empty input schema.

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

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

The description uses the specific verb 'List' and identifies the resource as 'topics created by the current user', which clearly distinguishes it from sibling tools like forum_list_topics or forum_get_latest_topics. The title 'List my forum topics' reinforces the personal scope.

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 clearly states the usage context: it returns topics created by the current user. This implies when to use it (for one's own topics) versus other forum listing tools, though it does not explicitly name alternatives or exceptions.

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. The description adds the prerequisite relationship to topic creation but does not cover additional behaviors like pagination or ordering. With annotations covering the safety profile, a score of 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?

Two sentences, each earning its place: the first states the action and scope, the second provides directional usage guidance. No redundancy or filler.

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

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

For a zero-parameter read-only tool with an output schema, the description is fully adequate. It covers what the tool does, when to use it, and the key output element (categoryId) needed downstream.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly emphasizes the need for the categoryId from the output, which is a useful semantic hint about the result even though it is not a 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?

The description explicitly states 'List all Discourse forum categories at community.argo.games' with a specific verb and resource. It also connects the purpose to topic creation, distinguishing it from sibling 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?

Provides clear context: 'Call this first when the user wants to post a bug report or feature request — you need the categoryId to create a topic.' It does not mention when not to use it or name alternatives, so it lacks explicit exclusion criteria.

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 mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavior: resolving the missing category identifier (slug or ID) from the category list automatically. This goes beyond the annotation-provided safety profile and clarifies expected input handling.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause adds value. It avoids repetition of schema details or annotation hints, maintaining high information density.

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

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

Given the tool's simplicity, 100% schema coverage, output schema presence, and annotations describing safety, the description fully covers what an agent needs: the core operation, parameter relationship, and how to discover categories. No notable gaps remain.

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

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

The schema already describes both parameters with 100% coverage. The description adds the key semantic detail that only one is required and the other is resolved automatically, which directly informs how the agent should populate the parameters. This is useful beyond the field-level descriptions.

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

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

The description states the tool's function precisely: "List topics in a specific forum category." This distinguishes it from siblings like forum_get_latest_topics or forum_search, and clearly identifies the resource (topics) and scope (specific category).

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 provides clear usage context: topics are listed per category, and category can be specified by slug or ID. It explicitly points to forum_list_categories for discovering categories, but does not explicitly exclude alternatives like forum_get_latest_topics for global views. This is strong guidance but lacks an explicit 'when not to use' statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral detail: 'Post bodies are returned as plain text (HTML markup is stripped),' which informs the agent about the return format. No contradiction with 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 two sentences: the first states the primary purpose, the second adds a relevant formatting detail. No redundant words or unnecessary 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 simple read operation with one parameter, full schema coverage, and an output schema present, the description covers the essential behavior (full content, all replies, plain text). No additional context is needed.

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

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

The input schema fully documents topicId as 'Numeric Discourse topic ID' with 100% coverage. The description adds no further parameter details, which is acceptable given the high schema coverage; 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?

The description clearly states 'Read the full content of a forum topic including all posts and replies,' specifying the action, resource, and scope. This distinguishes it from listing/searching tools like forum_list_topics and forum_search.

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

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

The phrase 'full content' and 'all posts and replies' provides clear context for when to use this tool: when a complete topic is needed. However, it does not explicitly name alternatives or exclusions, so it stops slightly short of full 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?

The description adds no behavioral context beyond the title. Annotations already indicate readOnlyHint=false and destructiveHint=false; the description does not disclose any additional traits such as auth requirements, effects on the topic, or post creation 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?

The description is a single sentence, front-loaded with the action and object. Every word earns its place, with no filler or redundant details.

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 2-parameter write tool with an output schema, the description together with the schema is sufficient. It could mention prerequisites like authentication or topic validity, but these are implied by the tool's nature and sibling naming.

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

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

The input schema provides 100% coverage with clear descriptions for both raw ('Reply body in Markdown') and topicId ('Numeric Discourse topic ID to reply to'). The description does not add any supplementary parameter information, matching the baseline for high schema coverage.

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

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

The description uses a specific verb ('Reply') and resource ('existing forum topic'), clearly distinguishing it from sibling tools like forum_create_topic (creates) and forum_read_topic (reads). The title and description align perfectly.

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

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

The description implies the use case—replying to an existing topic—and the sibling list provides context for alternatives. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls short of a 5.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds scope (topics and posts) and specific search syntax details (#category-slug, @username), which are not captured in annotations, enhancing transparency without contradiction.

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 concise sentences with no filler. The first sentence states the core action, the second provides syntax examples and a usage directive, all front-loaded and easy to parse.

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

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

For a single-parameter search tool with output schema and annotation coverage, the description is complete: it states scope, syntax, and usage context. No additional behavior like return format is needed given the output schema exists.

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 covers the parameter with a basic mention of Discourse syntax. The description expands on this by explaining what #category-slug and @username actually do (filter by category/author), adding semantic value beyond the schema.

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

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

The description states a specific verb ('Search') and resource ('forum topics and posts'), making the tool's function immediately clear. It also differentiates from sibling tools like forum_list_topics and forum_read_topic by focusing on search across both topics and posts.

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

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

Provides clear context for when to use the tool ('Always search before creating a bug report or feature request to avoid duplicates'), which is practical guidance. It does not explicitly enumerate when not to use alternatives, but the context is sufficient for typical use.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the fact that it retrieves details; it does not disclose error cases, permissions, or pagination behavior. This is acceptable since the tool is a simple read operation with output schema available.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, and lists representative details. It is concise with no redundant or filler 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?

The tool is simple: one parameter, a clear read-only purpose, and an output schema that presumably documents the return structure. The description is complete for this simple tool, and annotations cover safety and idempotency. No additional context is needed.

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

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

The schema has 100% coverage of the single parameter (campaignId) with a clear description. The tool description adds no additional parameter semantics beyond that. Baseline of 3 is appropriate since the schema fully documents the 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?

The description uses a specific verb ('Retrieve') and clearly identifies the resource ('an Argo campaign') along with the specific details returned (name, description, rule system, co-GMs). It clearly distinguishes from sibling tools like 'list_campaigns' (which lists campaigns) and 'update_campaign' (which modifies).

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

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

The description implies usage for fetching details of a single campaign, which is clear from the verb 'get' and 'Retrieve details'. However, it does not explicitly state when to prefer this over alternatives like 'list_campaigns' or mention any contextual exclusions. The context is clear but not explicit about alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the kind of data returned (members, campaigns, calendar metadata), giving the agent a better expectation of the response content without contradicting 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 a single, front-loaded sentence that immediately states the action and target. It contains no wasteful words and is highly scannable.

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

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

Given the simple single-parameter signature, full schema description, output schema availability, and annotations covering the safety profile, the description provides enough context for correct tool selection and invocation. The enumeration of content types makes the tool's scope clear without needing to explain return formats.

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

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

The input schema fully describes the only parameter (guildId) with 100% coverage. The description does not add additional parameter-level details, so the baseline of 3 is appropriate since the schema already carries the semantic burden.

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

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

The description uses a specific verb ('Retrieve') and resource ('full details of a guild'), and enumerates the included content (members, campaigns, calendar metadata). This clearly distinguishes it from siblings like list_guilds (lists guilds) and get_campaign (retrieves a campaign).

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 clearly implies usage when you need detailed information about a single guild identified by guildId. It does not explicitly state when not to use it or mention alternative tools, but the context is clear given the singular resource and the guildId parameter.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the return content (title, blocks, type properties), but does not go deeper into behavior such as error handling or pagination. With annotations present, this is an acceptable but not rich level of transparency.

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

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

The description is a single, front-loaded sentence that immediately states the action and resource. It contains no redundant information and every word contributes to understanding the tool's purpose.

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

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

This is a simple retrieval tool with only two required parameters, a fully described schema, an output schema, and comprehensive annotations. The description is sufficient to invoke the tool correctly. A minor gap is that it does not mention that entryId can be a title, but this is covered in the schema, so the overall completeness is high.

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

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

The input schema has 100% coverage with clear parameter descriptions (entryId as hex or exact title, campaignId as campaign ID). The tool description does not add any additional parameter semantics beyond the schema, so the baseline score of 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 uses a specific verb-resource pair ('Get full details of a specific mnemon entry') and lists the content included (title, blocks, type properties). This clearly distinguishes it from sibling tools like list_mnemons or search_mnemons, which list or find entries rather than fetch full details for a specific one.

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 clearly implies when to use this tool: when you have a specific mnemon entry ID or title and need its full details. It does not explicitly name alternatives or exclusions, but the 'specific' and 'full details' phrasing provides sufficient usage context. Sibling tools like list_mnemons suggest a contrast, but this is not stated.

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, covering the safety profile. The description adds 'single' as a scoping detail, but does not disclose any other behavioral traits such as response format, error behavior, or prerequisites. It aligns with annotations and provides minimal additional context.

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

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

The description is a single, concise sentence that conveys the essential purpose without any unnecessary words or repetition. It is well-structured and front-loaded with the action.

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

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

Given the tool's simplicity (two string parameters), existing annotations, and presence of an output schema, the description is adequate. It does not explain that both IDs are required, but that is captured in the schema. The description could be slightly more informative about what 'details' includes, but overall it is sufficient for a read-only getter.

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?

Input schema coverage is 100%, with both parameters (campaignId, sessionId) having brief descriptions. The tool description adds no further meaning about the parameters, their relationship, or expected values. With high schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Get details of a single campaign session.' It uses a specific verb ('Get'), identifies the resource ('campaign session'), and specifies scope ('single'), which distinguishes it from siblings like list_sessions and create_session. This is a clear and specific purpose statement.

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

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

The description implies usage through its wording ('Get details of a single campaign session'), but it does not explicitly state when to use this tool vs alternatives (e.g., list_sessions for multiple sessions). No exclusions or alternative tools are named, so usage guidance is only implicit.

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

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

The description adds the Owner/Admin-only restriction, which is not present in the annotations. However, it does not disclose other behavioral traits such as whether the user must already exist, whether an invitation is pending or immediate, or any side effects beyond the basic mutation. The annotations already indicate a non-read, non-destructive operation, so the added permission context is valuable but not extensive.

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 extremely concise: two short sentences that convey the action and the permission requirement. Every word is necessary, and the information is front-loaded.

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

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

Given the low complexity of the tool (two well-documented parameters) and the presence of an output schema, the description is largely sufficient for an agent to invoke the tool correctly. It covers the key permission gate but omits edge-case details like whether the user must not already be a member or how the invitation is delivered. These are not critical for basic invocation.

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

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

Schema description coverage is 100%, with both parameters clearly described ('Argo user ID to invite' and 'Guild ID'). The tool description adds no additional parameter meaning beyond confirming the invite action, so the baseline of 3 for high schema coverage is appropriate.

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

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

The description clearly states the action ('Invite a user to join the guild') with a specific verb and resource. It is distinct from many sibling tools, though it does not explicitly differentiate from similar actions like add_co_gm or send_friend_request.

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

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

The description provides a permission context ('Owner/Admin only') which implies who should use it, but it does not explicitly state when to use this tool versus alternatives like send_friend_request or add_co_gm. The usage guidance is only implied by the action name and the permission note.

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 annotations (read-only, idempotent), the description reveals the output includes access levels, an inline id display, structuredContent.idMap, and a rule to hide raw ids from users. These are specific behavioral details that help the agent know what to expect and how to handle results.

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 four sentences with no wasted words. It front-loads the core action, then provides usage context, output format details, and user-facing instruction—all relevant and succinct.

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 list tool with an output schema, the description covers the essential aspects: what is listed, the access-level information, the id/campaignName relationship, and how to refer to campaigns in prose. It is complete for its simplicity.

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

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

The tool has zero parameters, so the description need not explain parameter meaning. The baseline for 0 params is 4, and no additional parameter detail is required.

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

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

The description clearly states the tool lists Argo campaigns accessible by the current grant token, including access level. The verb 'List' and resource 'campaigns' are specific, and it distinguishes itself from sibling tools like get_campaign by describing its scope and intended first-use.

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

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

The description explicitly says 'Call this first when the user has not provided a campaign ID,' giving clear when-to-use context. It also provides display conventions and directs use of the returned id, which further clarifies how it fits into a workflow.

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 convey read-only, idempotent, and non-destructive behavior. The description adds no new behavioral details such as return format, ordering, or pagination, but it does not contradict 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?

A single, direct sentence with no filler words. It front-loads the verb and clearly names the resource.

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

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

Given the tool's simplicity, the presence of an output schema, and annotations covering safety, the description is complete enough. It clearly scopes the operation to listing co-GMs of a specific campaign.

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

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

The schema description covers the sole parameter (campaignId) fully. The tool description adds no parameter-specific meaning, but the high schema coverage makes this acceptable.

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

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

The description clearly states the action ('List') and the target resource ('the assistant GMs (co-GMs) of a campaign'). It distinguishes from sibling tools like add_co_gm and remove_co_gm by focusing on the read operation.

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 purpose implies when to use: when you need to see the co-GMs of a campaign. No explicit exclusions or alternatives are provided, but the context is clear for a simple listing 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scope context ('accepted friends') but does not disclose behavioral details like pagination, sorting, or return format. This adds some value beyond annotations but is not extensive.

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

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

The description is a single sentence of five words, front-loaded with the action and resource. Every word earns its place, with no redundant or vague 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 simple list tool with zero parameters, rich annotations, and an output schema, the description is complete. It states the purpose and scope clearly, and return values are presumably defined in the output schema.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description correctly focuses on the action and scope; there is no parameter information needed.

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

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

The description 'List the current user's accepted friends' uses a specific verb and resource, with the qualifier 'accepted' clearly distinguishing it from sibling tools like list_received_friend_requests and list_sent_friend_requests. It is immediately clear what the tool does and how it differs from friends-related 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?

The description provides clear context by specifying 'current user's accepted friends', which implicitly excludes pending or sent requests. However, it does not explicitly name alternative tools or state when-not-to-use, so it falls short of a 5 but provides solid contextual 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=true, idempotentHint=true, and destructiveHint=false. The description adds the returned member fields (id, role, status, invitedAt, joinedAt), but since an output schema exists, this is supplementary. No additional behavioral traits like pagination, auth requirements, or rate limits are disclosed.

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

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

The description is a single sentence, directly front-loaded with the operation, and contains no redundant words or information. Every part 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?

Given the tool's simplicity, the presence of a full output schema, and read-only annotations, the description is sufficiently complete for an agent to understand what the tool does and what it returns. No additional detail is necessary.

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

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

Schema coverage is 100% for the single parameter guildId, which already has a description ('Guild ID.'). The description adds no parameter semantics beyond what the schema provides, so the baseline of 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 uses the specific verb 'List' and identifies the resource 'members of a guild' with enumerated fields (id, role, status, invitedAt, joinedAt). This clearly distinguishes it from sibling tools like list_guilds or list_co_gms.

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

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

The description provides no guidance on when to use this tool versus alternatives such as invite_guild_member, remove_guild_member, or set_guild_member_role. It does not mention exclusions or alternative tools, leaving the agent to infer usage purely from the name and sibling context.

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 mark readOnly/idempotent/non-destructive, and the description adds valuable context: the required guild.read scope, the output fields, and the inline/idMap structure. This goes beyond annotations to explain authentication needs and output format.

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, each adding distinct value: purpose/scope, required scope, and output handling guidance. No redundancy or filler.

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

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

Complete for a read-only listing tool: purpose, auth requirement, output fields, and usage notes are all covered. With an output schema present and robust annotations, the description fills all necessary 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?

The tool has zero parameters, so the description cannot add parameter-level meaning. Per the baseline for 0-param tools, a score of 4 is appropriate. The description does enhance understanding of the returned data (e.g., idMap), but that falls under output 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?

The description states a specific action ('List the guilds the current user belongs to') with clear output details (role, member count, campaign count). This clearly distinguishes it from sibling tools like get_guild or list_guild_members by focusing on the current user's guild memberships.

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

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

The description gives explicit downstream usage guidance: use the returned guildId verbatim for other tools and refer to guilds by name in prose. It does not explicitly contrast with alternatives like get_guild, but the scope 'current user belongs to' makes the intended use 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=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by disclosing the exact response breakdown (outgoing edges, incoming edges, flat list with entryId/title/type/relationshipTypes), which is beyond what annotations provide.

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

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

The description is two sentences: the first states the action and output structure, the second gives practical examples. Every sentence is informative with no redundancy.

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

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

The tool is a read-only relationship lister with a clear output schema, so the description adequately covers purpose and expected results. The main gap is the lack of parameter explanation, but the simplicity and annotations prevent it from being incomplete.

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

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

The input schema provides no descriptions (0% coverage), and the description only mentions 'a mnemon entry' without explaining entryId or campaignId. It fails to clarify the purpose of campaignId, leaving the agent to infer its meaning from the parameter name alone.

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

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

The description clearly states the tool lists relationships of a mnemon entry and specifies the output structure (outgoing, incoming, flat list). It distinguishes this from siblings like get_mnemon or list_mnemons by focusing on relationships rather than the entry itself or all entries.

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

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

The description provides explicit use cases ('find members of a faction, allies/enemies of an NPC') which guides when to use the tool. It doesn't explicitly mention when not to use it, but the examples and context clearly differentiate it from relationship creation/deletion tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral detail: case-insensitive substring filtering, pagination semantics with hasMore/nextOffset, response contents (title, entryId, idMap), and the instruction to use entryId verbatim. This goes beyond what annotations convey and clarifies the tool's operation without contradicting them.

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

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

The description is dense but every clause earns its place: purpose, filter semantics, alternative tool, pagination behavior, response shape, and entryId usage. It is a single coherent paragraph with no filler or repetition, making it highly informative yet concise.

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

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

Given the tool's five parameters, output schema, and sibling tools, the description covers all essential aspects: what it lists, how filters work, how pagination works, what the response contains, and how to use identifiers. It is fully self-contained and sufficient for an agent to select and invoke the tool correctly.

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

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

Even though schema coverage is 100%, the description enriches parameter meaning: it specifies that title is a case-insensitive substring on title only, gives examples for type, explains limit default and maximum behavior, and details offset/nextOffset pagination semantics. This adds genuine value beyond the raw schema.

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

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

The description opens with 'List mnemon (lore/memory) entries for an Argo campaign,' a specific verb plus resource that clearly identifies the tool's function. It also distinguishes itself from search_mnemons by explicitly stating that search_mnemons is for finding entries by content, while this tool lists entries with optional filters.

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

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

The description gives explicit guidance: use this tool for listing mnemon entries with optional title/type filters, and explicitly directs users to search_mnemons for content-based lookup. It also explains pagination usage ('when hasMore is true, call again with offset = the returned nextOffset') and entryId handling, providing clear when-to-use and alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds the key behavioral nuance that the list only shows requests 'awaiting your response' (pending ones). This goes beyond the structured data and clarifies the exact scope. No contradictions.

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

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

A single, concise sentence that fully communicates the tool's purpose without wasted words. It is front-loaded and immediately understandable.

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 list with no parameters and an output schema present, the description is complete. It covers the essential purpose and scope; the output schema handles return details.

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

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

The tool has zero parameters, so the description need not explain parameter usage. Baseline for 0 params is 4, and the description adds no unnecessary info.

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

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

The description clearly states the tool lists incoming friend requests awaiting response. The verb 'List' and the resource 'incoming friend requests' are specific, and the phrase 'awaiting your response' distinguishes it from list_sent_friend_requests.

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

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

The description implies when to use the tool (viewing received friend requests that are pending) but does not explicitly mention alternatives or exclusions. Sibling tools like list_sent_friend_requests and accept/reject are not referenced, so the guidance is implicit 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 readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying that only pending requests are included, which is not explicitly 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?

The description is a single, concise sentence that immediately conveys the core purpose. No unnecessary words or redundant 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 parameters, clear annotations, and an output schema present, the tool's behavior is fully specified. The description covers the only nuance (pending filter) needed for correct usage.

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

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

The tool has zero parameters, so there is nothing to explain. The schema coverage is trivially 100% and the description does not need to compensate, making the baseline of 4 appropriate.

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

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

The description clearly states a specific action (List) on a specific resource (outgoing friend requests), and adds the filter 'still pending' to further narrow scope. This distinguishes it from sibling tools like list_received_friend_requests and list_friends.

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

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

The phrase 'outgoing' and 'still pending' clearly imply this tool is for viewing sent-but-not-yet-accepted requests. It does not explicitly mention alternatives, but the contrast with sibling tools is implied strongly by the wording.

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, covering the safety profile. The description adds the 'defaults to the current month' behavior, but does not disclose ordering, pagination, or response details beyond what the output schema likely covers. This is consistent with the mid-level calibration example.

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

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

The description is a single, front-loaded sentence that immediately states the action and resource, with no wasted words or repetition. It is appropriately concise for a simple list operation.

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

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

Given the simple read-only nature, full schema coverage, rich annotations, and presence of an output schema, the description is complete enough. It states what is listed (campaign sessions), the filtering scope (month), and the default behavior, while the schema handles parameter requirements.

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 all parameters (campaignId, year, month) already described including defaults. The description only repeats the month default and adds no new parameter semantics beyond the schema.

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

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

The description uses a specific verb ('List') and resource ('campaign sessions') with a clear temporal scope ('for a given month') and default behavior. This distinguishes it from sibling tools like get_session (single session) and create_session/update_session.

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

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

The description implies the tool is for listing sessions by month, but it does not explicitly contrast with get_session or mention when to use list_sessions over other session-related tools. There are no exclusions or alternatives stated, so guidance is only implicit.

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

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

The description restates the action implied by the tool name and adds no behavioral details beyond what the annotations already declare (readOnlyHint=false, destructiveHint=true). It does not disclose side effects such as whether the request is permanently removed or if any error occurs when the request does not exist.

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

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

The description is a single concise sentence with no filler. It communicates the action, the object, and the target in a compact form.

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

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

Given the simple one-parameter interface, the presence of an output schema, and clear annotations, the description is sufficient for an agent to use the tool. It might be improved by noting whether rejecting a non-existent request is an error, but the existing structured data covers the essential 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?

The input schema already fully describes the single parameter userId with its meaning ('Argo user ID of the counterparty'). The tool description only references 'the given user' without adding any further parameter-specific detail, so it adds no value beyond the schema.

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

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

The description uses a specific verb ('Reject') and identifies the resource ('incoming friend request') and actor ('from the given user'). This clearly distinguishes it from sibling tools like accept_friend_request and cancel_friend_request.

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 word 'incoming' provides context that this is for requests received from others, which distinguishes it from cancel_friend_request (for outgoing requests). However, it does not explicitly clarify when not to use it or mention alternatives by name, 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?

The annotations already indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is covered by structured data. The description adds meaningful behavioral context by stating 'Owner-only or self-removal,' which specifies the required authorization and the condition under which removal can occur. It does not contradict 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 exceptionally concise, consisting of two short sentences that convey both the action and the permission rule. No redundant information; every word contributes to the tool's understanding.

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

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

For a simple two-parameter destructive operation with complete schema coverage and annotations, the description is adequate. It states the action and permission rule, and the output schema exists, so no need to explain returns. It could explicitly mention consequences or irreversibility, but the destructive annotation covers that, so the description is sufficiently complete.

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?

Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description does not add additional parameter-level semantics beyond what the schema already provides; the word 'co-GM' in the description aligns with the userId description but does not offer new syntax or constraints.

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

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

The description clearly states the action ('Remove'), the target ('co-GM'), and the scope ('from a campaign'). It distinguishes itself from sibling tools like add_co_gm and list_co_gms by focusing specifically on removal, and even includes permission constraints, making the purpose unmistakable.

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

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

The description provides context that this operation is for removing a co-GM and is restricted to the campaign owner or the co-GM themselves, which acts as a usage condition. However, it does not explicitly mention alternatives (e.g., that add_co_gm is for adding) or exclusions for other user types, so it falls short of fully explicit 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 destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds the Owner/Admin-only permission constraint, which is useful beyond annotations. It does not describe side effects or irreversibility, but the annotation covers the destructive nature.

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

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

The description is two short sentences, front-loaded with the action and permission context. Every word earns its place with no redundancy.

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

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

For a simple two-parameter destructive action with annotations and a full schema, the description provides the essential context: what it does and who can do it. The presence of an output schema and clear parameter descriptions reduces the need for more detail. Minor lack of explicit return behavior or consequences is acceptable given the tool's simplicity.

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

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

Schema description coverage is 100%, with both parameters (userId, guildId) having clear descriptions. The tool description does not add additional parameter semantics, but none are needed given the schema already fully explains them.

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

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

The description uses the specific verb 'Remove' with the resource 'member from the guild', clearly distinguishing it from sibling operations like set_guild_member_role or remove_co_gm. The action is unambiguous and matches the tool name.

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

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

The description provides clear context that this operation is restricted to Owner/Admin, indicating who may use it. However, it does not explicitly contrast with alternative tools (e.g., remove_co_gm) 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial context beyond this: case-insensitive substring matching, per-hit field-match reporting, up to 3 body snippets with blockId correspondence to get_mnemon, visibility scoping, and limit/hasMore behavior. No contradictions with annotations exist.

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 four sentences, front-loaded with purpose, followed by usage guidance, then output details. Every sentence adds value: case-insensitive behavior, sibling distinction, hit reporting, snippet targeting, visibility, and pagination. No fluff or redundancy; exceptionally well-structured.

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

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

Given the tool's complexity, an output schema exists, and annotations are provided, the description covers all necessary contextual grounds: what is searched, how results are structured (field matches and snippets), how to use snippets for subsequent updates, user visibility constraints, and pagination. Nothing critical 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 the baseline is 3. The description adds minimal parameter-level detail beyond the schema; it restates limit defaults and query semantics already present in the schema. However, it does clarify the blockId relationship for the query parameter's output, which slightly enriches context, but not enough to push above baseline.

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

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

The description opens with a specific verb and resource: 'Full-text search across mnemon titles, tags, and body content' with case-insensitive substring semantics. It clearly distinguishes from the sibling tool list_mnemons by stating when search_mnemons is preferred, making its purpose unmistakable.

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

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

Explicit guidance is provided: 'Prefer this over list_mnemons when looking for entries by what they contain' names the alternative and gives a concrete example query. It also implies when not to use it (when listing all mnemons is the goal), satisfying the when-to-use vs. alternatives criterion.

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 indicate that this is a write operation (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds no further behavioral context such as side effects, permissions, or failure scenarios, nor does it explain what happens after sending (e.g., pending state). Thus, it fails to add value 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 description is a single, short sentence that directly and efficiently communicates the tool's function. It is front-loaded with the verb and resource, with no unnecessary words or redundancy.

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

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

The tool is simple with one well-documented parameter and an output schema present. The description, combined with schema and annotations, provides enough information for basic usage. However, it lacks any note about potential preconditions (e.g., not already being friends) or the outcome of the request, which would make it more complete, but given the simplicity, it is nearly sufficient.

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

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

The schema description for userId is 100% covered, already explaining it as 'Argo user ID of the counterparty.' The tool description does not add any additional meaning or usage details about the parameter, so it carries no extra value beyond the schema.

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

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

The description clearly states the verb ('send') and resource ('friend request') and specifies the recipient ('another Argo user'), making it easy to understand. It also distinguishes from sibling tools like accept_friend_request, cancel_friend_request, and reject_friend_request by indicating the initiation of a request.

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

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

The description implies usage when a user wants to send a friend request, but it does not explicitly state when to use this tool versus alternatives like cancel or accept. There is no mention of exclusions or alternatives, so the usage context is only implied.

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 indicate a non-read-only, idempotent, non-destructive operation. The description goes beyond annotations by warning that promoting a user to Owner transfers the guild and advising confirmation with the user. This is valuable side-effect disclosure that isn't captured in the structured fields, though it could further mention consequences of demoting an owner.

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, no filler. The first sentence states the action and allowed values; the second provides a critical caveat. Every word earns its place, and the most important operational detail (ownership transfer) is front-loaded.

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

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

With an output schema present, the description doesn't need to explain return values. It covers the main behavioral nuance (ownership transfer) and permission requirement, making it complete for a simple role-setting tool. Missing minor details like whether changing a role from Owner to Member is allowed or revokes ownership, but those are inferable from the 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?

The input schema covers all three parameters with descriptions, including the role enum. The description adds minor context about role semantics (e.g., Owner, Admin, Member) and the ownership transfer side effect, but doesn't need to explain parameters further since the schema already provides 100% coverage.

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

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

The description uses a specific verb ('Change') with a clear resource ('a guild member's role') and enumerates the possible values ('Owner, Admin, or Member'). This distinguishes it from sibling tools like remove_guild_member or invite_guild_member, so the agent knows exactly what operation this performs.

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

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

The description implies usage context (when changing a member's role) and notes a prerequisite ('Owner/Admin only') but does not explicitly state when to use this vs alternatives or provide exclusion criteria. It's clear enough for obvious use cases, but lacks explicit guidance about hierarchy or edge cases like demoting an owner.

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