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

The annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'Accept' implies a mutation. The description adds context that the share is 'pending' and 'from another organization', which is useful. However, it does not disclose side effects, reversibility, or permission requirements. The description adds some value beyond annotations, but not significantly.

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, focused sentence with no redundancy or extraneous detail. It is concise and front-loaded with the core 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?

While the tool has a single required parameter and an output schema (so return values are covered), the description is incomplete for correct invocation. It fails to explain what share_id refers to, how to obtain it, and what happens after acceptance. For a mutation tool with minimal annotations, this is a significant 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?

The schema description coverage is 0%, so the description carries the full burden of explaining the parameter. The description does not mention share_id at all, nor how to obtain it (e.g., from a list of pending shares). An agent would have no idea what value to provide or where to find 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 states a specific verb 'Accept' and a specific resource 'a pending template share from another organization'. It is clear what the tool does and it differentiates from siblings like sigma_list_shared_templates (which lists shares) and sigma_deploy_template_to_folder (deployment). However, it does not mention the effect of acceptance (e.g., the template becomes available for use), which would add clarity.

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 versus alternatives. It does not mention that the share must first be listed via sigma_list_shared_templates to obtain the share_id, nor does it state any prerequisites or exclusions. The agent is left to infer usage.

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 not read-only and not destructive; the description adds the important confirmation gate ('Requires confirm=True') and explicitly labels it mutating. It does not add details like idempotency or duplicate behavior, but the additive nature is clear.

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

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

The description is compact and front-loaded: purpose first, then mutation/confirm requirement, then parameter details. Every sentence adds necessary information without padding.

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

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

For a two-parameter mutating tool with an output schema, the description covers the required inputs and the confirmation behavior. It could mention duplicate handling or permission requirements, but the org scope and entry format are sufficient 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%, and the description compensates by defining the entries structure: each item must have 'ip' and 'scope' with the allowed scope values, plus an optional 'description'. It also clarifies that confirm must be set to true, which is essential given its default false in the schema.

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

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

The description names a specific resource ('IP allowlist entries'), action ('Create/add'), and scope ('for the organization'), and includes the API version. This distinguishes it from sibling tools like sigma_list_allowed_ips and sigma_remove_allowed_ips.

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

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

It states the operation is mutating and requires confirm=True, which gives useful context. However, it does not explicitly say when to choose this over the list/remove sibling tools or provide any when-not/exclusion guidance.

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

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

Annotations already cover readOnly=false, destructive=false, and idempotent=true, so the bar is lower. The description adds context by mapping 'annotate' to 'Can Use & Annotate' and 'usage' to 'Can Use', which clarifies the permission semantics. It does not explain side effects or prerequisites, but the annotation profile covers the main safety traits.

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 front-loaded: the core action appears in the first sentence, followed immediately by the two parameters that need clarification. There is no filler or repetition of schema property names.

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 an output schema and annotations that cover safety, so the description does not need to document return values or idempotency. It is still missing usage differentiation from generic grant tools and a clearer definition of grantee_id. Overall it is adequate but not complete for an agent deciding among many sibling grant operations.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaningful value for grant_type and permission by listing allowed values and their human-readable meanings. However, it leaves connection_id and grantee_id entirely to inference from their names, so it only partially compensates 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 verb and resource: 'Add a grant to a connection.' This clearly identifies the operation and distinguishes it from list/delete grant tools. It does not explicitly differentiate itself from the generic sigma_create_grant sibling, so it falls just short of a 5.

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

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

No guidance is given about when to use this tool versus sigma_create_grant, sigma_grant_workspace_access, or sigma_grant_workbook_access. The description only explains parameter values, not the context or exclusions that would help an agent choose correctly.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive nature is covered. The description adds the specific target and action, but it does not disclose potential behavioral nuances like duplicate handling, whether the policy must already exist, or permission requirements.

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

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

The description is a single sentence with no filler. It front-loads the verb and object, and every word contributes to the core 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?

For a simple two-parameter mutation with an output schema, this is minimally viable. However, there is no guidance on obtaining valid IDs, behavior on duplicates, or relationship to other deployment lifecycle tools, leaving some practical 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?

Schema description coverage is 0%, so the description must compensate. It partially does by mapping policy_id to 'deployment policy' and inode_ids to 'workbooks/reports', but it never explicitly labels the parameters or explains what an inode ID is, leaving room for confusion.

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 ('Add') and resource ('workbooks/reports to a deployment policy'), making the operation clear. It does not explicitly contrast with siblings like sigma_list_deployment_documents or sigma_create_deployment, but the action and target are unambiguous enough to distinguish it.

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 adding workbooks or reports to an existing deployment policy. However, it provides no explicit context about prerequisites, such as requiring a valid policy_id, or when to choose this over related deployment tools like sigma_create_deployment or sigma_archive_deployment.

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 not destructive (destructiveHint=false). The description 'Add a bookmark' is consistent but adds no extra behavioral context such as idempotency, permissions required, or side effects. With annotations present, the description adds minimal value beyond stating the resource type.

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 clear sentence with no wasted words. It is front-loaded with the core action. However, it is under-specified, but that issue is captured by other dimensions. For conciseness alone, it earns a high score.

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 complexity of the action (a write operation with an opaque body parameter) and the absence of schema descriptions, the description is inadequate. An agent cannot determine how to construct the body, what fields are expected, or what the output schema represents. The presence of an output schema does not compensate for the missing input guidance.

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%. The description provides no explanation of what 'workbook_id' refers to or what the 'body' object should contain. Since 'body' has additionalProperties: true with no schema, the description is the only source of semantic guidance, and it offers none, leaving the agent to guess the required 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 states a specific verb ('Add'), a specific resource ('a bookmark'), and a target ('to a workbook'). It clearly distinguishes from the sibling 'sigma_list_workbook_bookmarks' which lists bookmarks, so there's no ambiguity about the action.

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 given on when to use this tool, what prerequisites exist (e.g., needing a valid workbook_id), or how it differs from other 'add' operations like sigma_add_workbook_schedule. The description does not reference alternatives or conditions.

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 non-read-only, non-destructive, open-world operation. The description adds no behavioral context such as whether creating a schedule overwrites existing ones, what permissions are required, or what side effects may occur.

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 no redundant wording. However, the second sentence defers essential information to external docs instead of providing it, slightly reducing its 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?

The body parameter is an open object with no schema, and the description provides no structure, defaults, or examples. Given that this is a mutating operation with sibling schedule tools, an agent lacks enough information to construct a valid request without leaving the tool context.

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

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

Schema description coverage is 0%, so the description needed to explain workbook_id and body. It only says 'See Sigma docs for schedule body schema,' which is a pointer to external documentation rather than usable parameter semantics. The agent is left without the actual structure of the body object.

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') and the resource ('a scheduled export for a workbook'), which matches the tool name. It is specific enough to identify the tool's purpose, though it does not explicitly differentiate it from sibling sigma_create_report_schedule.

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 given on when to use this tool versus alternatives like sigma_list_workbook_schedules, sigma_delete_workbook_schedule, or sigma_create_report_schedule. The only directive is to consult external Sigma docs, which does not help an agent decide between 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the specific scope: describing capabilities rather than performing actions. It doesn't contradict annotations but also doesn't add significant behavioral context beyond what's already provided.

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 is front-loaded with the verb and subject. No wasted words, and it's appropriately sized for a tool with no parameters.

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

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

For a tool with no parameters and an output schema that likely defines the response, the description sufficiently conveys the tool's purpose. It doesn't specify the exact format of the output, but that's covered by the output schema. The tool is simple enough that the description is complete for its intended 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?

The tool has zero parameters, and the schema has 100% coverage (empty). Per the baseline rule for zero-parameter tools, a score of 4 is appropriate since there are no parameters to document. The description doesn't need to explain anything about parameters.

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: to describe the Sigma REST API's capabilities. It uses a specific verb 'describe' and resource 'Sigma REST API capabilities', and it's distinct from sibling tools that perform specific operations like listing reports or duplicating workbooks. However, it doesn't explicitly differentiate from siblings, but the distinction is obvious from the name and description.

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 doesn't provide explicit guidance on when to use this tool versus siblings. Its purpose as a capabilities overview implies it's for understanding the API before using specific operations, but no alternatives are named and no exclusions are stated. This leaves usage timing to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, covering the destructive nature. The description adds the confirm=True requirement, which is not in the annotations and is crucial for safe invocation. It does not describe side effects (e.g., what happens to related deployments or resources) but given the annotations cover the core behavioral trait, this is adequate.

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 states the action and the critical confirm requirement. Every word 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?

Given the tool has only 2 parameters and is a straightforward delete operation, the description is minimally sufficient. It covers the action and the confirm requirement, but it does not mention what happens after deletion (e.g., whether the policy is permanently removed or recoverable) or any prerequisites like the policy being in a certain state. With annotations already flagging destructiveness and the output schema likely providing return details, this is acceptable but not rich.

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. It mentions confirm=True but does not explain what confirm means (e.g., 'set to true to confirm deletion') or what policy_id refers to. The schema only provides types and defaults, so the agent gets little guidance on how to populate these fields beyond the bare mention.

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 ('Delete (archive)') and the resource ('deployment policy'). It is unambiguous and distinguishes this tool from sibling operations like list, get, or create deployments, which are named differently.

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 the key requirement 'Requires confirm=True,' which is a usage condition. However, it does not explicitly explain when to use this tool versus alternatives (e.g., when a policy is no longer needed) or when not to use it. The condition is present, but the broader usage context is implied rather than 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 indicate readOnlyHint=false and destructiveHint=false, so the description need not repeat that this is a mutation. However, it adds no behavioral context such as how duplicates are handled, whether existing memberships are preserved, or what permissions are required. The phrase 'in one call' hints at batching but is minimal.

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 with no filler. It is appropriately short and the key point (bulk addition) is front-loaded. However, brevity here comes at the cost of substantive guidance.

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

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

Even though an output schema exists, the description is incomplete for a mutation tool. It does not explain side effects, error conditions, or edge cases (e.g., what happens if some member_ids are invalid). The two-parameter tool has no parameter documentation, so the overall description is inadequate for safe 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 0%, so the description must compensate by explaining the parameters. It does not mention team_id or member_ids at all, leaving the agent to guess that member_ids is an array of member identifiers. No format, constraints, or requiredness are disclosed.

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 clear action ('Add multiple members') and resource ('to a team') with a distinguishing hint ('in one call') that implies bulk operation. However, it does not differentiate from the sibling tool sigma_update_team_members, which could also be used for adding members.

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

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

No guidance on when to use this tool versus alternatives like sigma_update_team_members or sigma_list_team_members. No exclusions, prerequisites, or contextual cues are provided, leaving the agent to infer appropriate 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?

The description adds valuable behavior beyond annotations: it lists tenants, obtains tenant-scoped tokens, lists and syncs each connection, uses bounded concurrency, and returns an error if token exchange is unavailable. This provides auth requirements and operational detail 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 compact and front-loaded with the core purpose, followed by a brief process summary and a note on dependencies. The 'Phase C' reference is slightly implementation-specific, but overall the description is focused and does not waste words.

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 explains the bulk multi-tenant algorithm, auth requirements, and error behavior, and the output schema covers return values. However, it omits the semantics of the sole parameter, dry_run, which is essential for safe invocation of a bulk write operation. This is a significant completeness 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?

The only parameter, dry_run, is not mentioned in the description at all. Schema description coverage is 0%, so the description was responsible for explaining this parameter, and it fails to do so. An agent cannot tell whether the default true means no writes happen or what effect dry_run has.

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 ('sync') and resource ('connections') across all tenant organizations, and outlines the multi-step process. The 'across all tenant organizations' scope clearly differentiates it from single-connection sync tools like sigma_sync_connection.

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 clearly conveys when to use this tool: for bulk syncing across all tenants, and it explicitly notes the multi-tenant auth prerequisite (for_tenant method) and the need for PyJWT. It does not explicitly name alternative tools or exclusion conditions, but the scope and prerequisites are sufficiently 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 convey that this is a mutating (readOnlyHint=false), non-destructive operation. The description only restates the PATCH endpoint and adds no behavioral detail beyond that — no mention of email uniqueness validation, impact on the member's login/SSO identity, permission requirements, or reversibility, which matters given openWorldHint=true.

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 9-word sentence that conveys the operation and endpoint with zero waste. The core action is front-loaded and 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 output schema covers return values and annotations cover safety profile, but for a state-changing tool with openWorldHint=true and zero parameter documentation, the description leaves meaningful gaps: no parameter semantics, no usage routing, and no side-effect disclosure. For a 2-param mutation it is under-specified.

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 must compensate by explaining the two parameters. It only implies that member_id is the {id} in the URL path and new_email is the new address; it does not specify email format, uniqueness expectations, or any constraints on these values.

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

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

The description names a specific verb ('Change') and resource ('a member's email address'), making the tool's scope unambiguous. The email-specific focus inherently distinguishes it from the broader sibling sigma_update_member, so an agent can select it correctly without inspecting schemas.

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 given for when to use this tool versus alternatives like sigma_update_member, nor any mention of prerequisites such as the member needing to exist or the email needing to be unique. Agents must 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?

Beyond the annotations, the description explicitly discloses that the operation mutates state and requires confirmation, which are important behavioral details an agent needs before calling. It does not contradict the annotations; in fact, it expands on the readOnlyHint=false signal with a concrete prerequisite.

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 three short sentences and every sentence adds value: the purpose, the mutating behavior with confirmation, and a concrete parameter hint. It is front-loaded and free of 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?

The output schema covers return values, and the confirm requirement is stated, but the provider_config object is open-ended with additionalProperties=true and no schema description. The description should explain more of the expected object structure, especially since the tool configures both providers and models yet only provider names are mentioned.

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 carries the burden for parameter meaning. It adds that provider_config is a specification dict and lists valid provider names, which is useful. However, it leaves the full structure of the provider config ambiguous, does not explain how models are specified, and only implies confirm semantics by saying confirm=True 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 names the operation as configuring the organization's AI provider and models, with a specific verb and resource. It is distinct from the report/workbook-focused siblings, but it does not explicitly contrast itself with nearby org-settings or agent tools like sigma_update_org_setting, so it falls just short of a 5.

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

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

The description gives concrete invocation guidance by stating this is a mutating operation and that confirm=True is required. It provides clear context for using the tool, but it does not name alternative tools or conditions for when not to use it, so it lacks explicit 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 already indicate a non-read-only, non-destructive operation. The description adds useful behavioral context: the conversion is one-way, creates a new report, and destination_folder_id defaults to My Documents. This goes beyond the structured annotation 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 short and front-loaded: the primary operation is stated first, followed by a compact parameter list. Every sentence adds value, 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?

Given the simple parameter set, existing output schema, and annotations, the description covers the key information an agent needs: what the tool does, all parameters, and default behavior. No critical calling details are 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 0%, so the description fully compensates by explaining all three parameters: workbook_id is the ID to convert, name is required by the API, and destination_folder_id is optional with a default of My Documents. This provides meaning the schema alone lacks.

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: 'Convert a workbook to a report' and clarifies it is 'one-way, creates a new report.' This clearly distinguishes it from sibling tools like sigma_duplicate_report or sigma_create_report.

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 it—when a workbook needs to become a report—and 'one-way, creates a new report' gives some constraint. However, it does not explicitly mention alternatives or when not to use this tool, leaving usage guidance mostly 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 signal this is a write operation (readOnlyHint=false, destructiveHint=false), and the description adds only the verb 'Copy,' which is already in the tool name. It does not disclose behavioral nuances such as whether the original workbook is untouched, what happens on name conflicts, or any permission prerequisites. With annotations present, the description adds minimal additional context beyond the fact that a copy is created.

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

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

The description is two sentences with no filler. The main action is front-loaded, and the only parameter note is brief and directly relevant. Every word earns its place, making it an exemplar of concise documentation.

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 operation and the optional naming parameter. An output schema exists, so return-value details are not required. However, for a mutation tool with openWorldHint=true, it lacks any mention of potential side effects, success/failure conditions, or prerequisites. It is minimally sufficient but not thorough.

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 explains the optional 'name' parameter and its default behavior ('Defaults to the original workbook name'). It does not explain workbook_id or member_id, but those are self-explanatory from the tool name. Since schema coverage is 0%, the description partially compensates by documenting the non-obvious parameter, while leaving the obvious ones to inference.

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

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

The description clearly states the verb 'Copy' and the resource 'a workbook' with a specific destination ('a member's My Documents folder'). It is distinct from sibling tools like sigma_duplicate_workbook by the explicit target location, though it does not explicitly name alternatives. The purpose is unambiguous and actionable.

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 (e.g., sigma_duplicate_workbook for copying within the same workspace) and offers no exclusions. The use case is implicit from the purpose, but the agent receives no explicit routing information for selecting this tool over its many sibling copy/duplicate operations.

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, so the mutation nature is covered. The description adds no additional behavioral context such as side effects, permissions, rate limits, or error conditions. It only mentions required input fields, which is more about parameter semantics. No contradiction exists.

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

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

The description is two sentences with no waste. The primary purpose is front-loaded, and the second sentence adds the most critical input constraint. It is appropriately sized for the tool's simple parameter count.

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 single complex 'spec' parameter with nested objects, and the description only lists four required fields without detailing the full structure or how to construct a valid spec. While an output schema exists, the input construction is under-specified, and the openWorldHint suggests additional properties are allowed but not documented. An agent would struggle to correctly build the spec.

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 lists four required fields (name, folderId, schemaVersion, pages with elements) inside the 'spec' object, giving some structure to an otherwise opaque free-form object. However, it does not specify types, formats, or additional allowed properties, leaving significant ambiguity.

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') and the resource ('data model'), and specifies it takes a JSON code representation. It distinguishes from sibling tools like update or get by explicitly indicating creation. The required fields are listed, adding 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 implies usage when a new data model needs to be created, but it does not explicitly mention when to use this over alternatives (e.g., update_data_model) or any prerequisites. No exclusions or alternative tool references are provided, so guidance is only implied by the verb 'create'.

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 not read-only, and the description adds only the generic fact that it creates something; it does not disclose side effects, required prior state, idempotency, or what a successful creation returns. openWorldHint true hints at external effects, but the description itself offers no behavioral detail. 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?

Single sentence, no fluff, and the verb is front-loaded. It is concise, but the brevity crosses into under-specification, which is better penalized in other dimensions.

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 creation tool with a free-form body object, high sibling ambiguity, and zero parameter documentation, a one-sentence description leaves the agent unable to construct a valid call. The output schema exists but is not visible in the description, and the body structure is entirely unexplained.

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

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

Schema description coverage is 0%, and the description does not mention 'name' or 'body' at all. 'body' is an opaque object with additionalProperties true, so an agent has no idea what fields to supply; the description fails to compensate for the missing schema 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 identifies a specific action ('Create') and resource ('deployment policy'), so an agent knows this is a creation operation. It does not, however, explain what a deployment policy is or how it differs from a 'deployment' referenced by sibling tools, so it isn't a 5.

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

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

The description gives no guidance on when to choose this tool over the many deployment-related siblings (e.g., sigma_list_deployments, sigma_archive_deployment, sigma_add_deployment_documents). There are no prerequisites, exclusions, or alternative references, so an agent must infer context from the tool 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?

Annotations already indicate a write operation (readOnlyHint=false) that is not destructive (destructiveHint=false), so the description does not need to restate this. However, the description adds no behavioral context beyond the annotations, such as effects on existing resources, permission requirements, or error behavior. This is adequate but not enriched.

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 and free of filler, with the core action front-loaded. It is slightly under-specified, but as a matter of conciseness and structure it is efficient 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?

Given the low parameter count, the presence of an output schema, and annotations covering the write/non-destructive nature, the description is minimally workable. The main gaps are the meaning of parent_id, any required hierarchy context, and when folder creation is appropriate, so the description is adequate but not 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 0% and the description does not mention either parameter. The property names 'name' and 'parent_id' are somewhat self-explanatory, but the description fails to clarify what parent_id refers to (e.g., parent folder versus workspace) or any naming constraints, so the agent gets little semantic help beyond raw schema types.

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 and resource: 'Create a folder.' It is clear and distinct from sibling tools like sigma_create_workspace or sigma_create_workbook, even though it does not explicitly call out those alternatives. It is minimally more than the title, but it does convey the tool's purpose without ambiguity.

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

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

The description gives no guidance about when to use this tool versus alternatives, nor any prerequisites or context such as parent folder requirements. There are no exclusions and no mention of related folder operations, leaving the agent to infer usage entirely from the tool name and schema.

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 it is a write operation (readOnlyHint false), not destructive (destructiveHint false), and idempotent (idempotentHint true). The description's 'create or update' aligns with these hints but adds little new behavioral context. It does clarify the dual create/update semantics, which is slightly beyond the annotations, so a middle score 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?

A single sentence that states the action and the required fields upfront. There is no wasted wording, and the most critical information (required body keys) is front-loaded. This is an appropriately sized and structured description.

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 a loosely typed body and no schema documentation, the description should provide more context: what types of grants (workspace, workbook, connection) this applies to, what values are valid for permission, and whether there are optional fields. It also does not mention any prerequisites or error conditions. The description is usable but leaves significant ambiguity for an agent to call it correctly.

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

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

The schema only defines a 'body' object with additionalProperties true, providing zero documentation of its fields. The description compensates by listing the required keys (inodeId, granteeId, permission, type), which is essential for constructing a valid call. However, it does not explain the meaning of each field, possible permission values, or any optional parameters, so it partially fills the gap but not completely.

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

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

States a clear action ('Create or update a grant') and identifies the required body fields, which gives a specific resource and inputs. It does not explicitly differentiate from sibling grant tools like sigma_grant_workspace_access or sigma_add_connection_grant, but the name and required fields make the general purpose clear.

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 instructs what the body must include but provides no guidance on when to use this tool versus other grant-related tools. There is no mention of alternatives, exclusions, or contextual triggers such as 'use for resource-level grants' or 'prefer sigma_grant_workspace_access for workspace access'. The agent is left to infer appropriate usage.

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 signal mutation (readOnlyHint=false) and non-destructive (destructiveHint=false), and the description's 'Create' is consistent. However, it adds little beyond that: no mention of what happens on duplicate emails, permission requirements, or any side effects. For a mutating tool, this is a minimal contribution.

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 short—one sentence plus a type list. It's efficient but under-specified; while concise, it omits critical usage and behavioral details. A concise but incomplete description warrants a middle score.

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 four parameters, an output schema, and a mutating operation, the description is too sparse to be complete. It gives no guidance on required fields, response shape, or edge cases. The output schema may help, but the description itself leaves significant gaps for an agent to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does partially by enumerating allowed values for member_type ('admin', 'creator', 'viewer') which the schema lacks (no enum). However, the other three parameters (email, first_name, last_name) receive no semantic clarification beyond their names, so compensation is incomplete.

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') and the resource ('a new member'), which distinguishes it from update/deactivate operations. Listing the member_type values adds specificity. However, it doesn't explicitly contrast with sibling tools like sigma_onboard_member, so it's not a perfect 5.

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

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

No guidance is provided about when to use this tool vs. alternatives such as sigma_update_member, sigma_deactivate_member, or sigma_onboard_member. The description gives no context on prerequisites or scenarios that would select this tool over siblings, leaving the agent to infer usage.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description's 'create' action is consistent with these, so there is no contradiction. However, the description adds zero behavioral context beyond what the annotations already convey—no mention of permissions required, partial-success behavior, or what the open-world body implies about report creation. The bar is lower given annotations, but the description still contributes nothing.

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 technically short, but this is under-specification rather than effective conciseness. There are no useful details to front-load; the only line is a restatement of the tool's name.

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

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

For a tool with a completely open body parameter, an output schema, nested objects, and openWorldHint=true, a one-word restatement is grossly inadequate. The agent cannot construct a valid call or anticipate return behavior. The description fails to compensate for the schema's openness and the total lack of parameter documentation.

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

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

Schema description coverage is 0%, and the single 'body' parameter is an open object (additionalProperties: true) with no structure defined. With zero coverage, the description must compensate and explain what body should contain, but it says nothing. An agent has no idea what fields or payload to supply for the mandatory body 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 'Create a report.' simply restates the tool name and title ('Sigma Create Report') with no added specificity. It names a verb and resource but gives no hint about what a report is in Sigma context, what structure it requires, or how it differs from sigma_duplicate_report or sigma_create_report_schedule. Effectively 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?

There is no guidance on when to use this tool versus alternatives. With over 100 siblings including similar-sounding creation tools, the description provides no context about what distinguishes creating a report from duplicating one, creating a report schedule, or other report operations. No when-to-use or when-not-to-use information is present.

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 (readOnlyHint false, destructiveHint false, openWorldHint true) already declare the operation is not read-only and not destructive, but the description adds no further behavioral detail. It does not mention side effects (e.g., whether the schedule is immediately active, whether it replaces existing schedules), required permissions, rate limits, or what the returned output schema contains. With a creation-oriented tool, this is a meaningful 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 a single short sentence with no filler, which is concise on the surface. However, it is under-specified for the tool's complexity: the body parameter is an open object, and there are many sibling schedule-related tools. This is not appropriate conciseness; it sacrifices necessary information for brevity.

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

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

The tool has a nested free-form body parameter, an output schema, and multiple closely related siblings, making a richer description necessary. The description only states the high-level action and leaves out scheduling details, parameter expectations, and distinctions from other schedule tools. Given the available annotations and schema, this is incomplete and requires additional inference by the 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?

Schema description coverage is 0%, and the description does not compensate at all. It does not explain what 'body' should contain, how report_id is used, or any expected format for the scheduled export configuration. Given the body parameter is a free-form object with additionalProperties true, this is a severe omission; an agent would not know how to construct a valid request.

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 ('Create'), a resource ('a scheduled export'), and a scope ('for a report'). This clearly distinguishes it from the sibling sigma_export_report (likely an immediate export) and sigma_list_report_schedules (listing, not creating). It is not a tautology and conveys the core function, but it could more explicitly differentiate from sigma_add_workbook_schedule.

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

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

There is no guidance on when to use this tool versus alternatives with similar functionality, such as sigma_export_report, sigma_add_workbook_schedule, or sigma_list_report_schedules. The description offers no context about scheduling parameters, report prerequisites, or cases where another tool should be chosen. No comparison or exclusion is provided.

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 signal that this is a non-read-only, non-destructive operation, and the description adds no further behavioral context. It does not mention idempotency, side effects, prerequisites, or what happens to existing deployments or policies.

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 redundant wording. It is concise, though the brevity contributes to the lack of parameter and behavior 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?

Despite having an output schema and annotations, the tool has a complex, undocumented body parameter, and the description does not compensate. An agent cannot determine the required policy structure or deployment-related details from this definition alone.

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

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

The schema describes only an opaque 'body' object with additionalProperties true and no property descriptions, so schema coverage is 0%. The description says nothing about what fields the body should contain, leaving the agent without the information needed to construct a valid request.

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 clear verb and resource: 'Create a source swap policy.' It also adds a useful context, 'for automated deployments,' but does not explain what a source swap policy is or explicitly differentiate itself from sibling swap-related tools beyond the operation 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 phrase 'for automated deployments' implies the intended use case, so an agent can infer when this tool is relevant. However, there is no explicit guidance on when to create a policy versus listing/getting policies, or when to prefer source swaps over this policy-based approach.

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 (mutation) and destructiveHint=false, so the safety profile is covered. The description adds that color is required by the Sigma API and defaults to 'cyan', which is useful behavioral detail. However, it does not mention potential duplicate-name conflicts or any side effects beyond creation, so it adds limited value.

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

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

The description is concise, with two sentences that front-load the core purpose and then detail the color parameter. Every sentence serves a purpose, and the parameter details are integrated 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?

For a simple 2-parameter create tool with an output schema present, the description covers the essential purpose and parameter details. It does not mention return values or error conditions, but the output schema likely covers that. It is slightly incomplete regarding when to use this vs tagging existing objects, but that is more about usage guidelines than 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?

With schema description coverage at 0%, the description carries the burden for parameter meaning. It thoroughly explains the color parameter, listing valid values and the default. The name parameter is implied by context ('tag') but not explicitly described (e.g., uniqueness constraints). This is a strong compensation for color but leaves name slightly under-specified.

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 verb ('Create') and resource ('a new tag'), and adds context about its use for version promotion, which distinguishes it from sibling tools like sigma_list_tags and sigma_delete_tag. The purpose is unambiguous and immediately understandable.

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 mentions it's 'used for version promotion', giving some usage context, but it does not explicitly contrast with alternative tools such as sigma_tag_workbook or sigma_tag_data_model, nor does it state when this should be used instead of creating a tag differently. It implies usage but leaves the decision 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?

Annotations already indicate this is non-read-only and non-destructive, but the description adds no behavioral context beyond that, such as uniqueness constraints, default team membership, admin requirements, or side effects. It is not contradictory, but it provides little added 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 concise sentence with no wasted words and is immediately clear. However, it borders on under-specification because it largely restates the tool title.

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 create operation, the description plus schema provide enough shape to make a basic call, and the output schema handles return-value expectations. Still, it lacks uniqueness, permission, and side-effect context, so it is minimally viable rather than fully 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 0%, and the description does not explain the 'name' or 'description' parameters. The property names are self-evident, but the description adds no semantic guidance around uniqueness, length, formatting, or how the description field is used.

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 and resource: 'Create a new team.' It is distinguishable from sibling get/list/update/delete team tools by the create verb, though it does not explicitly contrast with them or clarify what kind of team is being created.

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 about when to use this tool versus related creation tools like sigma_create_member or sigma_create_workspace. Prerequisites, required permissions, and any exclusions are also absent, leaving usage entirely 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?

The annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'create'. It does not mention side effects, permission requirements, tenant creation limitations, or anything about what happens after creation, though 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 a single concise sentence with no fluff and the primary action front-loaded. It is under-specified, but that issue is penalized in other dimensions rather than this one.

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 operation with two parameters and a large sibling toolset, the description is too sparse. It lacks guidance on the optional body, tenant setup fallout, uniqueness constraints, or relationship to other tenant-related tools, so an agent has limited context 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%, and the description does not explain either parameter. 'name' is partially self-explanatory from its schema name, but the 'body' parameter's purpose, format, and possible fields are completely undocumented, leaving a significant 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?

The description clearly names the action ('Create') and resource ('a tenant organization'), which tells an agent this is a creation operation for tenants rather than a read/list operation. It does not meaningfully differentiate among the many sibling 'create' tools beyond the resource name, so it misses the top score.

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 given for when to use this tool versus alternatives such as sigma_list_tenants, sigma_get_tenant, or other create operations. The description only restates the action and provides no context, prerequisites, 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 already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds minimal behavioral detail beyond the schema: it explains the default_value behavior ('assigned when no override exists') but does not disclose potential side effects, idempotency, duplicate-name handling, or response format. Since the annotations cover the safety profile, this is adequate but not rich.

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

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

The description is two short sentences: a clear one-line purpose followed by a compact parameter list. It is front-loaded with the core action and purpose, with no redundant or filler content. Every element earns its place, and the formatting (parameter names and brief explanations) is 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 simple 3-parameter create tool with an output schema (not shown), the description provides the essential context: the purpose (RLS/dynamic parameters) and parameter meanings. It does not mention prerequisites (e.g., permissions) or error conditions, but these are not critical for such a straightforward operation. The tool is well-scoped, and the description is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It provides examples for name ('Region', 'CustomerID') and explains default_value as a fallback string, which adds meaning beyond the raw schema. However, it does not elaborate on the description parameter beyond 'Optional description' (already implied by a default of ''), nor does it mention constraints like uniqueness or length. It covers all parameters but not deeply.

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') and resource ('user attribute'), and adds the specific use case ('for RLS or dynamic parameters'). It distinguishes from siblings like sigma_set_user_attribute_for_teams (which assigns attributes) and sigma_update_user_attribute_for_* (which modifies existing ones), though it doesn't explicitly name them. The purpose is specific enough for an agent to select this tool over other user-attribute operations.

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 creating new attributes (vs. updating or assigning) and provides a clear purpose ('RLS or dynamic parameters'). It does not explicitly mention alternatives or when not to use it, but the 'create' action and the parameter explanations (e.g., 'default_value' as a fallback) give sufficient context for appropriate use. It lacks explicit exclusions but is not misleading.

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 communicate that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the useful behavioral nuance that the workbook is created empty and placed in a folder, but it does not disclose permission requirements, side effects, or response behavior beyond that.

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 words. It efficiently conveys the core action, but its brevity leaves some semantic gaps that prevent a perfect score.

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 an output schema and annotations, the description is minimally viable, but it omits important context such as required parameter meaning, whether the folder must pre-exist, and any naming constraints. It is adequate for a straightforward call but not fully 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 0%, so the description must compensate for the lack of parameter documentation. It only hints at folder_id through 'in a folder' and says nothing about name or the optional description parameter. The schema alone provides no explanatory text, leaving the agent to infer parameter semantics from names 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 states a specific verb ('Create'), a precise resource ('workbook'), and a key qualifier ('empty') that distinguishes it from template-based creation or duplication. It clearly identifies the destination scope ('in a folder') and is unambiguous even among a large set of 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?

The phrase 'empty workbook' implies this is for creating a blank workbook rather than using sigma_create_workbook_from_template or sigma_duplicate_workbook, but it never explicitly says when to choose this tool over alternatives. No exclusions or when-not-to-use conditions are provided.

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 readOnlyHint=false and destructiveHint=false, so the write nature is clear. The description adds a useful constraint: 'Only public is currently supported,' which is a behavioral limitation. However, it does not disclose other side effects like whether creating an embed replaces existing ones or requires specific permissions.

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

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

The description is short and front-loaded with the primary purpose, followed by structured parameter clarifications. Every sentence serves a purpose; there is no fluff. The parameter explanations are neatly listed, though a bit more structural separation would be ideal.

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 an output schema, so return values need not be explained. The description covers the core parameters and the key limitation. However, it leaves edge cases unspecified, such as what happens if source_id is provided for source_type 'workbook' or whether the workbook must be 'published' before embedding. This is acceptable for a simple create but not fully comprehensive.

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 0% description coverage, so the parameter explanations carry the full burden. The description explains embed_type, source_type, and source_id, including allowed values and conditional requirement. It omits workbook_id, but that is self-explanatory given the purpose. This meaningfully adds value beyond the bare 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 action and resource: 'Create an embed for a workbook.' This is a specific verb-resource pair that distinguishes it from sibling tools like sigma_list_workbook_embeds, which is a listing operation. No ambiguity about what the tool does.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives or any exclusions. It only states the purpose and parameter semantics. There is no mention of prerequisites like workbook existence or when to prefer this over export or share mechanisms.

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 a behavioral trait beyond annotations: that the created workbook includes real visuals. However, it does not disclose side effects, permissions, or reversibility. Annotations already indicate a write operation (readOnlyHint false), so the description adds some value but not rich 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?

Two sentences with no filler, the core action is front-loaded, and the differentiator follows immediately. Perfectly concise for the information provided.

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 too sparse for a 3-parameter tool with an output schema. It does not explain how to obtain template_id or folder_id, nor what the output contains. Given the complexity and the need to route correctly among many sibling tools, this is 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?

Schema description coverage is 0%, and the description provides no explanation of the parameters (template_id, folder_id, name). An agent cannot infer the meaning or source of these parameters from the description, leaving a significant 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?

The description clearly states the verb (create) and resource (workbook from template), and adds a strong differentiator: 'the only programmatic way to get charts/tables.' This distinguishes it from sigma_create_workbook (likely blank) and sigma_duplicate_workbook, 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 implies when to use it (when you need visuals) but does not explicitly name alternatives or state when not to use it. The phrase 'the only programmatic way' is a usage signal, but it lacks explicit guidance on choosing between this and sibling tools like sigma_create_workbook or sigma_deploy_template_to_folder.

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 readOnlyHint=false (mutation) and openWorldHint=true (external effects). The description 'Create a new workspace' adds no additional behavioral detail, such as side effects, required permissions, or what happens on success. It essentially restates the name without informing the agent about any consequences beyond the obvious.

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 wasted words. It is front-loaded and direct. However, it is quite sparse, but that aligns with the tool's simplicity. It earns a high score for conciseness without penalizing the omissions that are captured under other dimensions.

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?

Despite having a simple schema and an output schema present, the description provides no practical context for a create operation—such as typical use cases, required permissions, or relationship to other workspace tools. An agent lacks sufficient information to confidently invoke this tool in a complex workflow, making it incomplete for realistic 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 input schema contains one parameter ('name') with no description (0% coverage). The description does not mention this parameter or its meaning. While the parameter name is self-explanatory, the description adds no semantic value to guide the agent on what value to provide, such as format, uniqueness, 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 states a specific verb ('Create') and a specific resource ('workspace'), clearly differentiating it from siblings like sigma_list_workspaces, sigma_get_workspace, and sigma_delete_workspace. It leaves no ambiguity about the operation's intent.

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 usage guidance is provided. The description does not mention when to use this tool versus other workspace-related tools, nor does it specify any prerequisites (e.g., admin permissions) or conditions. It simply states the action without 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the confirmation-gating behavior ('Requires confirm=True'), which is useful context beyond the annotations. It does not describe downstream effects on the member's data or access, but the destructive hint covers the core risk.

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

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

Two short sentences communicate the action and the critical confirmation requirement. Every sentence is necessary and front-loaded; no filler.

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

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

For a low-complexity tool with an output schema and destructive annotations, the description is minimally sufficient: it states the action and the guardrail. It could be more complete by noting irreversibility or how to reactivate, but those are not strictly required for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the confirm parameter's role (must be true) but does not mention member_id, which is arguably self-explanatory. Overall, partial compensation 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?

The description states a specific verb and resource ('Deactivate a member'), which clearly distinguishes it from create/update/list member tools. It could explicitly contrast with siblings, but the action 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 requirement 'Requires confirm=True' is a necessary invocation condition, which is helpful. However, there is no guidance on when to use this tool versus alternatives like update_member or delete_member, or any preconditions for deactivating a member.

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 flag destructiveHint, but the description adds a critical behavioral requirement—confirm must be set to true—that is not obvious from the schema (which defaults confirm to false). This goes beyond annotations. However, it doesn't explain consequences of not confirming or other side 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?

The description is two short sentences: purpose first, then the confirm requirement. It is succinct, front-loaded, and has no 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?

The tool is a simple delete operation and the annotations cover destructiveness. The confirm requirement is noted, but the description lacks context on when to use this tool over other grant-deletion tools, and it doesn't mention prerequisites like permissions. Output schema presumably covers return values, so this is adequate but not rich.

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 only mentions the confirm parameter requirement. It offers no clarification for grant_id or connection_path_id, leaving their meaning and format largely undefined. The description adds minimal value beyond the schema's field 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 'Delete a grant from a connection path,' which specifies the verb, resource, and scope. This distinguishes it from other delete tools like sigma_delete_workspace_grant, which target different resources.

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. It only mentions the requirement for confirm=True, which is a pre-condition, not a usage criterion. There is no mention of exclusions or selection logic relative to sibling tools.

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

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

Annotations already mark destructiveHint=true. The description adds the specific behavioral requirement that confirm=True must be set, which is a critical detail not covered by annotations. It does not describe irreversibility or side effects, but the destructive annotation already implies permanence, so the added confirm requirement earns credit.

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, well-structured sentence that front-loads the action and identifier, then states the necessary confirmation flag. No fluff; 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 destructive tool with an output schema and strong annotations, the description covers the essential invocation details: the target identifier and the confirm requirement. It could mention irreversibility explicitly, but the destructive annotation covers that. Minor gap: it doesn't note any permission prerequisites, but this is not critical for a basic delete.

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 explains both parameters: 'by its inode ID' clarifies inode_id, and 'Requires confirm=True' clarifies the confirm flag. Both are explicitly addressed, fully compensating for the lack of schema 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 clearly states the action (delete), the resource types (file/workbook/data model), and the identifier (inode ID). This distinguishes it from sibling tools like sigma_update_file or sigma_list_files.

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 (e.g., when not to delete, or that sigma_update_file should be used for modifications). It only states the confirm requirement, which is a prerequisite but not a usage 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 indicate destructiveHint=true and readOnlyHint=false, so the description correctly aligns with 'Delete'. It adds the specific requirement that confirm=True is necessary, which is a key behavioral gate. However, it does not disclose any other effects like reversibility, cascading deletes, or permission requirements beyond the annotation baseline.

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 with two sentences, front-loading the purpose and key requirement. It is efficient and easy to parse, though it might be slightly too terse to be fully informative.

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 simple delete operation with an output schema and annotations covering safety, the description is minimally sufficient. It provides the essential confirm requirement but lacks guidance on identifying tag_id and potential side effects. For a destructive action, more context could be expected, but the combination of annotations and minimal description reaches an adequate level.

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 mentions confirm but not tag_id, and does not explain what tag_id represents, how to obtain it, or the exact format expected. The confirm parameter is partially explained via 'Requires confirm=True', but its purpose beyond being a safety flag is not clarified.

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 'Delete a tag' with a clear verb and resource, distinguishing it from sibling tools like sigma_create_tag and sigma_list_tags. However, it does not elaborate on the scope or context of tags, but the core purpose 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites beyond 'Requires confirm=True'. It does not explain when deletion is appropriate or when other tag-related actions should be used instead.

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 aligns with the annotations: destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. It adds the confirmation guardrail ('requires confirm=True'), which is useful, but it does not disclose potential side effects, irreversibility, or permission requirements.

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

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

Two short sentences with zero filler. The core action is front-loaded, and the critical confirmation requirement is stated immediately. 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 destructive two-parameter operation, the description is functional but thin. The annotations and output schema cover safety and return value gaps, but the description does not mention permissions, cascading effects, or whether the team must be in a certain state before deletion.

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 needed to compensate. It adds important semantics for 'confirm' by stating it must be true despite the schema default being false. The 'team_id' parameter is not described, though its meaning is reasonably inferable from the tool name.

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 'Delete a team.' with a specific verb and resource, and the title reinforces it. It doesn't elaborate on scope or side effects, but it is unambiguous and distinguishable from sibling delete tools by naming the 'team' resource.

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

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

The description provides one actionable usage instruction: 'Requires confirm=True.' It does not explain when to choose this tool over alternatives, when not to use it, or any prerequisites. The guidance is clear but minimal.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description reinforces the destructive nature and adds the specific requirement of confirm=True, which is beyond what the annotations convey. It does not contradict any annotation and provides useful operational context for the agent.

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

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

The description is two short sentences with no filler. The core action is front-loaded, followed by the two most important caveats (destructive and confirm requirement). Every word contributes to the agent's understanding, and it is appropriately sized 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?

The description covers the essential operational requirement (confirm=True) and the destructive nature, and an output schema exists so return values need not be explained. However, it omits any mention of what happens if confirm is false, how errors are surfaced, or any side effects beyond deletion. Given the tool's simplicity and the annotation coverage, this is adequate but not comprehensive.

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 carries the full burden of explaining parameters. The description only mentions confirm (saying it is required to be true) but does not explain team_id or attribute_id. While the names are self-explanatory given the tool name, the lack of any parameter detail beyond confirm leaves a significant gap for an agent that needs to construct a valid call.

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

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

The description states a clear action (delete), a specific resource (user attribute assignment), and the scope (for a specific team). It distinguishes itself from sibling tools like sigma_delete_user_attribute_for_user and sigma_delete_user_attribute_for_tenant by naming the team scope, and it adds the critical confirm requirement and destructive warning, which are not present in the name alone.

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 mentions that confirm=True is required, which is a usage guideline for invocation. However, it does not mention when to use this tool versus alternatives like sigma_set_user_attribute_for_teams or sigma_update_user_attribute_for_teams, nor does it state when not to use it. The usage context is implied by the name and the destructive/confirm note, but not fully spelled out.

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

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

Annotations already include destructiveHint=true, and the description reinforces this with 'DESTRUCTIVE.' The description adds the confirm=True requirement beyond annotations, which is a meaningful behavioral guardrail. No contradiction with annotations (readOnlyHint=false, destructiveHint=true align).

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

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

Two short sentences, no fluff. The destructive warning and confirm requirement are front-loaded, making critical information immediately visible.

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 presence of an output schema, the description need not explain return values. The key behavioral context (destructive, confirm gate) is covered. The only minor gap is no explicit exclusions, but the tool is simple enough that this doesn't hinder 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?

Schema description coverage is 0%, so the description must compensate. It mentions 'confirm=True' which is not in the schema description, adding important semantic guidance for the confirm parameter. However, it does not explain attribute_id or tenant_org_id, but these are self-explanatory from the tool name and schema types.

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 exact action ('Delete a user attribute assignment'), the target resource ('for a specific tenant'), and explicitly flags destructiveness. While it doesn't name a sibling, the name itself is unambiguous and the description clearly distinguishes it from other user attribute tools (e.g., set, update, delete for user/team).

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 mentions the required confirm=True, which is a critical usage condition. It does not explicitly state when to use this tool versus alternatives (e.g., sigma_delete_user_attribute_for_user), but given the clear name and the explicit confirm requirement, usage context is mostly 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 destructiveHint=true, so the 'DESTRUCTIVE' callout is redundant but consistent. The description adds the requirement for confirm=True, which is not in the annotations, providing additional behavioral context beyond the structured data. 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?

One sentence with zero fluff. The action is front-loaded, and the critical safety requirement (confirm) is placed at the end, making it easy to parse. 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 an output schema, so return value documentation is covered elsewhere. The description covers the essential action, destructiveness, and the confirm requirement. It doesn't mention potential errors or prerequisites, but for a simple deletion this is acceptable. Could have elaborated on parameter semantics, but given the output schema, it is mostly 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 0%, so the description must compensate. It only explains the confirm parameter ('Requires confirm=True') and leaves attribute_id and user_id unexplained, relying on their self-evident names. For a tool with three parameters, this is insufficient given the lack of schema 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 a specific verb ('Delete') and a precise resource ('a user attribute assignment for a specific user'), clearly distinguishing it from sibling tools like sigma_delete_user_attribute_for_team and sigma_delete_user_attribute_for_tenant. The 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 explicitly states 'Requires confirm=True', giving a clear condition for use. It doesn't explicitly mention alternatives, but the phrase 'for a specific user' implies the distinction from other delete tools, and the destructive hint is reinforced. It lacks a 'when not to use' clause but is otherwise helpful.

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 flag the operation as destructive, and the description adds the critical behavioral requirement that confirm must be true to execute the deletion. This goes beyond the structured annotations by surfacing the confirmation guardrail. It does not detail side effects, but the destructive hint plus confirm requirement covers the essential behavior.

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

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

Two short sentences with no redundant phrasing. The action is front-loaded, and the confirmation requirement is stated directly. 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 straightforward destructive operation, the description conveys the action and the required confirmation flag. An output schema exists, so return-value details are unnecessary. It could mention irreversibility or what happens if confirm is false, but the annotations and the 'Requires confirm=True' statement provide sufficient 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 description clarifies that confirm must be set to true, adding meaning beyond the schema's bare boolean default. It does not explain workbook_id or schedule_id, but their roles as identifiers of the scheduled export are reasonably inferable from the tool name and description. Given 0% schema description coverage, this is partial but not full compensation.

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 specific verb 'Delete' and the resource 'a scheduled export', making the tool's purpose immediately clear. It also differentiates from siblings like sigma_list_workbook_schedules and sigma_add_workbook_schedule by signaling this is the destructive counterpart.

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 instruction 'Requires confirm=True' provides a clear prerequisite for invocation, which is helpful. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusion conditions. Usage is mostly implied by the tool's name and destructive nature.

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 destructive nature is known. The description adds the important behavioral requirement that confirm must be set to a truthy value, which is not evident from the annotations. This extra context about a required confirmation flag goes beyond what structured annotations provide, though side effects are not elaborated.

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 with the action front-loaded and the critical confirm requirement stated immediately after. No unnecessary words 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 destructive operation, the description is sparse. It covers the confirm requirement, and the output schema plus destructiveHint fill some gaps, but it leaves open questions such as whether deletion cascades to workspace contents, whether any dependencies block deletion, and what happens if confirm is false. Given the high stakes of deletion, more context would be valuable.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that confirm must be true to delete, adding meaning beyond the schema's default of false. However, the description says nothing about workspace_id, its format, or any constraints on that parameter. With two parameters and only one addressed, the compensation is only partial.

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

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

The description states a specific verb and resource: "Delete a workspace." This clearly identifies the tool's function and distinguishes it from sibling tools like sigma_delete_workspace_grant, which deletes a workspace grant rather than the workspace itself. However, it does not explicitly differentiate itself from alternatives, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives such as sigma_delete_workspace_grant or sigma_delete_team. It only states that deletion requires confirm=True, which is a prerequisite rather than a usage condition. No when-to-use or when-not-to-use context is offered.

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 the description reinforces this with 'DESTRUCTIVE'. More importantly, it adds the requirement that confirm must be true, which is not in annotations but is critical for execution. This goes beyond the structured metadata and provides essential 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 extremely concise: three short fragments that front-load the purpose and immediately highlight the destructive nature and confirmation requirement. There is zero waste and every piece 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 that an output schema exists (not shown) and annotations cover the destructive nature, the description provides the essential missing detail: the confirm requirement. It does not elaborate on side effects or return values, but these are covered by the output schema and the clear scope of the operation. Adequate for a straightforward delete action.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does not describe workspace_id or grant_id, only mentions confirm. The tool name gives a hint, but the description fails to clarify what a grant is or how to identify it, leaving the agent to infer parameter meaning from the tool 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 states a specific verb ('Delete') and resource ('permission grant') scoped to a workspace, clearly distinguishing it from siblings like sigma_grant_workspace_access (which creates grants) and sigma_list_workspace_grants (which lists them). The purpose 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 mentions a required confirmation parameter ('Requires confirm=True'), which is a usage requirement, but it does not explicitly compare to alternatives or state when not to use this tool. While the name implies its scope, it lacks explicit routing guidance versus related deletion tools like sigma_delete_workspace.

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 readOnly=false and destructive=false, and the description adds the two-step deploy-then-swap behavior, which is useful beyond the schema. It does not, however, disclose side effects such as whether a deployment record is created, what connection_mapping triggers, or any post-deployment state changes.

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 conveys the core workflow without padding. 'Full deployment' is a useful leading qualifier, and the optional source-swap behavior is stated efficiently.

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, return-value documentation is not needed. But the description is thin on operational context: it does not explain when the optional source swap occurs, how connection_mapping drives it, or how this relates to deployment-specific siblings like sigma_list_deployments or sigma_swap_template_sources. It is minimally adequate but leaves clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate, but it only loosely references 'a template into a folder' and 'swap its sources.' It does not explain template_id, folder_id, name, or connection_mapping, leaving the agent without semantics for three of four parameters.

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 clear verb and resource: 'instantiate a template into a folder, then optionally swap its sources.' This distinguishes it from a plain template-to-workbook creation or a bare source-swap operation, though it does not explicitly name a sibling it is not.

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 deployment' implies this is the complete end-to-end operation versus separately creating from a template and then swapping sources. However, it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives, so the agent must infer the intended selection 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?

The description goes well beyond the annotations by specifying the response forms (JSON/text/CSV vs base64 for PDF/XLSX/PNG), the 'processing' pending state, and the max_bytes payload cap. The annotations already mark it read-only and non-destructive, and the description adds meaningful behavioral context 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 compact and front-loaded: the main action in the first sentence, then return behavior, then the parameter note. Every sentence provides useful information 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?

The description covers the key operational details: return types, pending state, and payload limit. Since an output schema is present, return-value documentation is not required. The main gaps are the lack of guidance on where queryId comes from and what happens when max_bytes is exceeded, but the tool is still largely complete for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It explicitly explains max_bytes with a default value. query_id is given contextual meaning via 'by queryId', but its format, origin, or how to obtain it is not described. This is partial compensation for the missing schema 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 a specific verb ('Download'), a specific resource ('exported query result file'), and a precise key ('by queryId'). It also enumerates the possible return formats, making the tool's function unmistakable and distinct from export-related siblings like sigma_export_and_download.

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

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

Usage is implied: the agent must already have a queryId from an export operation and can poll while the query is 'processing'. However, it does not explicitly state when this tool should be chosen over related tools, nor does it mention that it pairs with an export step.

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

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

Annotations already indicate a non-read-only, non-destructive mutation. The description adds a modest amount of behavioral context by describing the clone as a new report with a specified name and destination folder, implying the original is left intact. It does not cover permissions, failure behavior, or whether report resources are copied, but the annotations cover the core safety profile.

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 'Duplicate a report.' before the parameter explanations. The repeated 'required by the API' is slightly redundant given the input schema's required array, but it is a minor inefficiency. No unrelated or filler content appears.

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, non-destructive duplicate operation with all three required inputs semantically documented and an output schema present, so the definition is sufficient for calling the tool correctly. The main missing piece is routing guidance among related report tools, but that is more of a usage-guideline gap than an invocation gap. It could be strengthened by explicitly stating that the original report remains unchanged, though 'duplicate' and 'clone' imply this.

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 carries the full burden for explaining parameters. It does so successfully: report_id, name, and destination_folder_id are each given a clear semantic role in the duplication process. This adds real meaning beyond the bare input schema and fully compensates for the missing parameter 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 opens with 'Duplicate a report.', which names a specific verb and resource and distinguishes this tool from siblings like sigma_duplicate_workbook. Although terse, it is unambiguous and clearly identifies what the tool operates on. The parameter notes about cloning into a destination folder reinforce the intended 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?

No usage guidance is provided. The description does not state when to choose this over sigma_create_report, sigma_export_report, or sigma_duplicate_workbook, nor does it mention preconditions such as access to the source report and destination folder. An agent must infer the appropriate context from the tool 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?

Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds useful context by stating that destination_folder_id defaults to the original folder when omitted, which is behavior beyond the annotations. It does not disclose deeper side effects like permission copying or whether the original is modified, but the annotations cover the core safety profile.

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 front-loaded with the core action in the first sentence. The parameter explanations are short, informative, and each earns its place. There is no filler or repetition of schema types.

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 straightforward duplication tool with an output schema and annotations covering mutation and destructiveness, the description is complete. It documents every parameter, including the optional destination folder behavior, and provides enough context for an agent to invoke the tool correctly without needing to inspect sibling tools.

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 carries the full burden of explaining parameters. It provides meaningful semantics for all three: workbook_id identifies the source, name names the clone and is noted as API-required, and destination_folder_id explains its default behavior. This fully compensates for the lack of schema 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 opens with a specific verb and resource: 'Duplicate an existing workbook.' It clearly distinguishes this from sibling tools like sigma_duplicate_report by naming the workbook as the target and using 'clone' as a synonym. The parameter list reinforces the resource being duplicated.

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 the verb 'duplicate' and the workbook resource, and it provides useful contextual behavior for destination_folder_id. However, it does not explicitly state when to prefer this tool over alternatives such as sigma_copy_workbook_to_member or sigma_create_workbook_from_template, nor does it mention 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?

Annotations already mark the tool as non-read-only and non-destructive, and the description adds meaningful behavioral context: it polls until ready, returns size info without content when max_bytes is exceeded, and returns base64-encoded content on success. These details go beyond the annotation flags and help set expectations for an agent, though it does not describe failure modes or timeout behavior.

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

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

The description is compact, with four sentences that front-load the core action and then list parameter specifics in a structured list-like style. Each sentence adds useful information, avoiding fluff. It is appropriately sized for the tool's complexity, though it could briefly mention timeout_seconds without much bloat.

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 has seven parameters and an output schema, the description covers the main behaviors (format, layout, parameter overrides, size limit, return encoding) but leaves gaps around timeout_seconds semantics and the precise role of element_id. While the output schema may clarify return structure, the polling timeout is a critical operational detail that an agent needs to set expectations. Overall it is adequate but not exhaustive.

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 explains several parameters (format, layout, parameters, max_bytes) with concrete examples and constraints, which is valuable given 0% schema coverage. However, it omits timeout_seconds entirely and only indirectly covers element_id via 'workbook/element'. This partial coverage leaves meaning for two of the seven parameters unspecified, so it does not fully compensate for the schema's lack of 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 clearly states the tool exports a workbook/element and downloads the result with polling. It specifies supported formats and the layout constraint, making the primary action unambiguous. However, it does not explicitly differentiate from sibling export tools like sigma_export_report or sigma_export_workbook, relying on the 'workbook/element' phrasing to imply 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 practical usage details (format, layout, parameters, max_bytes) but offers no guidance on when to choose this tool over alternatives. It never names sigma_export_report, sigma_export_workbook, or sigma_download_query_export, nor states conditions for selecting one over the other. This leaves the agent to infer applicability from sibling names alone.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds no behavioral context such as whether export creates a file, is asynchronous, or requires the report to be published. It only restates the action and formats, adding no transparency 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 short sentence with no filler; the format list is useful and front-loaded. It is concise to the point of under-specification, but 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 two-parameter tool with an output schema and annotations, the description covers the format values but omits usage context and the distinction from export-related siblings. It is minimally viable but leaves an agent to guess when this tool is appropriate.

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 the allowed format values ('pdf', 'png', 'csv', 'xlsx'), which the schema does not enumerate. It does not describe report_id, though the parameter name is self-explanatory.

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

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

The description states a specific verb and resource ('Export a report') and lists supported formats, making the core action clear. However, it does not differentiate from sibling tools like sigma_export_and_download or sigma_export_workbook, so an agent must infer the distinction.

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 given on when to use this tool versus sigma_export_and_download, sigma_download_query_export, or sigma_export_workbook. The description provides no context, prerequisites, 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 already cover safety hints; the description adds useful behavioral details: empty element_id exports the first page, and layout is only honored for pdf/png. It does not go into response/download mechanics, but the output schema covers the return shape.

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

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

Three short, front-loaded sentences with every line adding parameter or fallback information. No filler or duplication of the schema.

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

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

For a single-required-parameter export with an output schema and annotations, this description is complete: all optional parameters are documented with values and constraints, and the default page behavior is explicit.

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 carries the burden. It enumerates allowed format values, layout values, and element_id fallback behavior with conditional constraints. workbook_id is not described, but it is self-evident from the tool name and required property.

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 ('Export') with a specific resource ('workbook element') and immediately clarifies the fallback to the first page when element_id is empty. This distinguishes it from sibling tools like sigma_export_report by workbook 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?

It gives clear operational context (which parameters to set and default behavior), but it never names alternatives or states when not to use this tool. Sibling exports such as sigma_export_report and sigma_export_and_download exist, yet no routing guidance is provided.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds that it returns a reference (implying read-only) and details the content areas, but does not describe output format or any side effects. Since annotations carry the primary behavioral burden, a 3 is appropriate – the description adds useful context but not deep behavioral detail.

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

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

A single, focused sentence that front-loads the action ('Return a curated reference') and then lists specific content categories. The usage instruction is appended succinctly. No wasted words, 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?

For a zero-parameter, read-only reference tool with an output schema present, the description fully covers what the tool does and when to use it. It lists all major pitfall categories and gives a clear usage directive. Nothing an agent needs to decide whether to invoke this tool is missing.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter explanations, but none are needed. Baseline for 0 parameters is 4, which is appropriate here.

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

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

The description clearly states the tool returns a curated reference of Sigma formula pitfalls and enumerates the specific categories (column reference syntax, type requirements, NULL handling, aggregate vs row-level context, date function argument order, metrics vs calculated columns). This distinguishes it from all sibling tools, which are operational actions, while this is a knowledge/reference 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 instruction 'Use this before writing any Sigma formula expression' provides an explicit when-to-use directive. It doesn't explicitly state when not to use it or name alternatives, but given the unique nature of the tool (no sibling provides similar reference content), the guidance is sufficient. A small deduction for lacking an exclusionary 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?

The annotations already establish readOnlyHint=true and destructiveHint=false, so the read-only nature of the call is covered. The description adds no additional behavioral context beyond that, 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?

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the operation.

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