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

With no annotations, the description carries the full burden and does well: it warns of destructive action, irreversibility, and elevated permissions. It also mentions the return value (confirmation with count). It doesn't cover potential side effects like locking or partial failures, but covers the most critical aspects.

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 well-structured with clear warnings, argument list, and return statement. The use of emojis and formatting draws attention to important caveats without unnecessary fluff. It's appropriately sized for a destructive admin tool.

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 admin operation with 2 parameters and an output schema (indicated), the description is nearly complete. It covers permissions, irreversibility, parameters, and return value. The only minor gap is not explicitly defining what constitutes a 'child namespace', but the example and default make it understandable.

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

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

Schema coverage is 0%, so the description compensates by explaining both parameters: 'namespace' with an example and 'include_children' with its default value. It clarifies the meaning of child namespaces implicitly. This adds value beyond the raw schema, though it could be more explicit about the exact format or edge cases.

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 'Clear' and the resource 'references in a namespace', making the purpose unambiguous. It distinguishes itself from sibling tools like admin_delete_reference (single reference) by specifying 'all references' and the namespace 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 provides important context with the 'ADMIN ONLY' and 'DESTRUCTIVE' warnings, implying it's for special administrative operations. However, it does not explicitly state when to use this tool versus alternatives like admin_delete_reference or admin_list_references, leaving some inference to the agent.

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

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

With no annotations provided, the description carries the full transparency burden. It clearly flags ADMIN ONLY, DESTRUCTIVE, and 'cannot be undone,' which discloses the most important behavioral consequences. It also mentions the return as confirmation or error, though it does not detail side effects beyond the deletion itself.

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 and well-structured: a one-line purpose, two high-signal warnings, and a clear Args/Returns breakdown. There is no redundant filler, and the most critical facts are 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 a single required parameter, no nested objects, and an available output schema, the description covers what an agent needs: what the tool does, the required argument, the irreversible destructive nature, permission requirements, and the general return shape. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate for the schema's bare 'string' type. It does so by explaining that ref_id is 'The reference ID to delete,' giving the parameter purpose. It stops short of providing examples or format details, but for a single opaque ID this is adequate.

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 'Delete a specific cached reference,' which names both the action and the resource. The word 'specific' distinguishes this from sibling tools like admin_clear_namespace, which would operate more broadly, and from read/admin inspection tools.

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

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

The description states that the tool is admin-only and destructive, which gives important high-level cautions, but it does not explicitly say when to prefer this tool over admin_clear_namespace or when not to use it. Usage context is implied by 'specific' rather than clearly articulated.

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

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

No annotations are provided, so the description carries the burden. It discloses the return format (dictionary with statistics) and the permission requirement. However, it does not explicitly state that this is a read-only operation with no side effects. The verb 'Get' implies read-only, but the description doesn't confirm it won't modify cache state or that it is safe to call repeatedly. For an admin tool, that level of disclosure is expected.

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 well-structured: a one-line purpose, a permission warning, and a bulleted list of return contents. It front-loads the primary action and quickly communicates the key details. No wasted words; every line adds value.

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

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

Given that this tool has an output schema (has_output_schema: true), the description doesn't need to fully enumerate return fields. It already lists categories of statistics, which is sufficient context for an agent. It also includes the permission requirement. For a parameterless getter, this is complete. It might miss error conditions, but those are likely in the output schema or not critical for a simple admin stat call.

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

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

There are zero parameters, and schema coverage is 100% (empty properties). Per calibration, 0 params gives a baseline of 4. The description adds nothing about parameters because there are none, so the baseline holds. Nothing more is 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 clearly states 'Get detailed cache statistics' – a specific verb and resource. It lists the kinds of statistics returned (namespaces, active/expired counts, value types, config), which distinguishes it from sibling admin tools like admin_list_references or admin_delete_reference that manage individual references. The purpose is unmistakable.

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

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

The description implies usage: you'd call this when you need cache statistics. It warns 'ADMIN ONLY - Requires elevated permissions,' which is a constraint but not a when-to-use guide. It does not explicitly mention alternatives or when not to use it. With siblings like admin_list_references, the description could have noted 'use this for aggregate stats, not per-reference details,' but it doesn't.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that the tool requires elevated permissions, operates on cached references, and returns a dictionary that excludes the cached value. It stops short of explicitly saying the operation is read-only or describing error behavior, but 'Get' and 'look up' strongly imply a non-mutating operation.

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

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

The description is compact and well-structured: a one-sentence purpose, a permission warning, an args block, and a returns note. Every line contributes meaningful information with no filler or repetition.

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

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

For a simple one-parameter admin lookup with an output schema available, the description covers the essential auth and return-shape context. It is incomplete in usage guidance and parameter provenance: an agent still needs to infer when to pick this over get_cached_result and how to obtain a valid ref_id.

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 for the only parameter is 0%, so the description must compensate. It merely restates the parameter as 'The reference ID to look up,' which adds little meaning beyond the schema's field name and type. It does not explain where the ID comes from, what format it uses, or how it relates to sibling tools like admin_list_references.

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: 'Get detailed information about a cached reference.' It clearly differentiates itself from sibling lookup tools by noting this is reference info and that the value is not included, so an agent can distinguish it from get_cached_result.

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 marks the tool as admin-only and elevated-permission, which gives context about who should invoke it. However, it does not explicitly state when to use this tool versus get_cached_result or admin_list_references; the 'value not included' note implies get_cached_result might return the value, but this routing is left to inference.

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

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

With no annotations, the description carries the full burden and does well by disclosing the admin permission requirement, the return shape ('Dictionary with references list and pagination info'), and the max limit of 100. It does not mention side effects or performance characteristics, but this is a read-only listing operation and no contradictions are present.

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 well-structured and front-loaded: purpose, admin warning, then compact labeled sections for arguments and return. Every line provides necessary information without filler.

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

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

Given five optional parameters and an existing output schema, the description covers the operation, permission, parameter semantics, and return outline. Minor details like null namespace meaning 'all namespaces' or sorting order are not stated, but the optional defaults and schema make the behavior reasonably clear.

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%, yet the description fully compensates. It explains namespace with concrete examples, clarifies include_expired and include_preview, documents the limit maximum/default, and names offset as pagination. This adds meaningful semantics far beyond the bare 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 opens with 'List cached references with optional filtering,' which states a specific verb, resource, and scope. It stands apart from sibling tools like admin_delete_reference or admin_get_reference_info by clearly identifying this as a list 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 description clearly communicates the required elevated permissions ('ADMIN ONLY - Requires elevated permissions') and indicates filtering options. However, it does not explicitly name alternatives or state when to use this instead of tools like get_cached_result or admin_get_reference_info; the usage context is only implied by the verb 'list'.

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

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

With no annotations, the description carries the behavioral disclosure burden and does tell the agent what happens: when enabled, all traces include user_id, session_id, and metadata from MockContext, and a status dict is returned. It does not state whether disabling restores normal trace behavior or whether state persists across calls, but the primary side effect is 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 short and front-loaded with the core purpose, followed by the behavioral effect, a one-line parameter doc, and a return note. Every sentence earns its place; no filler or repetition.

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

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

For a simple one-boolean tool, the description covers purpose, effect, parameter, and return value, and an output schema exists. The main missing context is the relationship to set_test_context and reset_test_context, which could affect tool selection.

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

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

Schema description coverage is 0%, so the description must explain the parameter. The Args section defines enabled as the toggle ('Whether to enable test context mode') and notes the default True, which is enough for this single boolean 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?

Description uses a specific verb ('Enable or disable'), names the resource ('test context mode for Langfuse attribution demos'), and explains the effect on traces. It is clear, but it does not differentiate this tool from sibling tools set_test_context and reset_test_context, which appear to cover similar functionality.

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

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

The description gives a clear use case: testing Langfuse filtering and aggregation without a real FastMCP authentication setup. It does not explicitly mention alternatives or when not to use the tool, 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It does so thoroughly: it mentions Langfuse tracing with hit/miss status, that large results come back as references with previews, how pagination works, and that ref_id comes from previous tool calls. These are meaningful behaviors beyond the 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 well-structured with a lead sentence, bulleted use cases, an args section, returns, and bolded notes. It is slightly repetitive between the Returns paragraph and the Caching/Pagination sections, but the redundancy is minimal and the structure supports scanning.

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

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

The description covers the essential invocation context: when to use it, what each parameter does, caching behavior, pagination, and the source of ref_id. Given the output schema exists and the operation is a read-style cached lookup, this is nearly complete, though it could add more detail about defaults or missing-key behavior.

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

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

Schema description coverage is 0%, but the description compensates by documenting all four parameters: ref_id, page (1-indexed), page_size, and max_size (overrides defaults). The definitions are concise and actionable, though max_size's default behavior could be more precise.

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 clear and specific statement: 'Retrieve a cached result, optionally with pagination.' It also enumerates the concrete use cases (preview, paginate large lists, access full value), making the tool's purpose unmistakable and distinct from sibling admin/cache-stat 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?

The 'Use this to' bullets describe when to call the tool and how it should be used, including previewing and paginating. It does not explicitly name alternative tools or exclusions, but the guidance is clear enough for an agent to select it in the right 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it returns metadata but does not explicitly confirm it is read-only, has no side effects, or mention permissions or error conditions. For a getter, this is a notable gap.

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

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

The description is concise and front-loaded with the purpose. There is minor redundancy (mentioning metadata and then returning a Dict), but it remains short and focused.

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 getter, the description covers the return type and general purpose. However, it lacks detail on behavior when no trace exists, whether the operation is safe, and how it relates to sibling tools. The output schema is present, so return structure is partially covered, but edge-case context 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 fully descriptive; the baseline is 4. The description adds context about return values but no parameter semantics are needed. It does not need to compensate for missing parameter 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 uses a specific verb ('Get') and a clear resource ('information about the current Langfuse trace and context'). It explicitly mentions metadata and context values for debugging, which distinguishes it from sibling tools that enable/set/reset test context. Not a tautology.

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 a debugging use case but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. Siblings are set/reset tools, so the usage is inferable but 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation (check) and return value, but does not disclose whether the operation is read-only, whether any side effects occur, what happens on failure, or any permissions or rate limits. For a health check, it likely has no side effects, but this is not explicitly stated, leaving significant ambiguity.

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

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

The description is extremely concise, consisting of two short lines. The purpose is stated first, followed by the return value. There is no wasted text, and the structure is clear and 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 that the tool has no parameters, an output schema is present, and the tool is simple, the description is adequate. It states what the tool does and what it returns. It does not elaborate on the exact health status fields, but the output schema covers that. The only minor gap is that it does not mention any prerequisites or context, but for a health check, none are typically 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, so the schema trivially covers 100% of them. Per the rubric, a baseline of 4 applies when there are no parameters. The description adds no parameter-related information because none exists, which 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 purpose: 'Check server health status.' It names a specific resource (server health) and a specific verb (check). It also adds a concrete detail about the return value ('including Langfuse tracing status'), which distinguishes it from sibling tools, none of which relate to health monitoring.

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 usage context: you call this when you need to check server health. It does not explicitly mention when not to use it or name alternatives, but since there are no similar sibling tools, the context is clear enough. It lacks explicit exclusion criteria, so it does not reach 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?

No annotations are provided, so the description must disclose behavioral traits. It states that the tool resets to defaults, implying overwrite, but does not explicitly warn that existing context will be replaced, nor mention side effects, permissions, or reversibility. This is a significant gap for a mutation tool.

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

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

The description is brief and front-loaded with the purpose. However, the second sentence 'Returns: Reset context state.' is redundant given the output schema and adds no value, slightly reducing efficiency.

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 simplicity (no params, output schema present), the description is adequate but lacks behavioral detail such as whether the reset is destructive to the current context. It does not explain side effects or prerequisites, which would help an agent reason about consequences.

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% (trivially). The description adds no parameter information, but none is needed. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools.

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 ('Reset test context') and the target state ('to default demo values'), which is specific enough to distinguish it from siblings like set_test_context and enable_test_context. The verb-resource combination is unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives like set_test_context or enable_test_context. It does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that it affects user_id, session_id, and metadata sent to traces, and states the return includes updated context state. It does not detail side effects like persistence or system impact, but for a test utility this is acceptable. The description adds some context beyond the schema but is not exhaustive.

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 efficiently structured with a purpose statement, effect/use case, parameter list, and return note. It is front-loaded with the core purpose and avoids fluff. The Args/Returns sections are formatted clearly, though the Returns section could be redundant if the output schema already covers it, but it is acceptable.

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 test utility with 4 optional parameters and an output schema, the description covers the key aspects: what it does, when to use it, what parameters mean, and what it returns. It does not explicitly mention that all parameters default to null, but the schema conveys that. Overall, it provides enough 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 0%, so the description compensates by clearly explaining each parameter. It provides examples for each (e.g., 'alice', 'bob') and their roles. This goes beyond the schema's name/type pairs and gives meaningful context for correct usage.

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 'Set' and resource 'test context values', and immediately links it to Langfuse attribution demos. It explains the effect on traces and the use case for testing dashboard filters, distinguishing it from sibling tools like enable_test_context and reset_test_context.

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 clear context for use: 'Use this to test filtering by different users or sessions in the Langfuse dashboard.' It implies when to use (when needing to change context) but does not explicitly mention when not to use or compare with alternatives. It gives adequate guidance without exclusions.

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