mcp-server-sigma

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.5
Disambiguation2/5
Many tools have overlapping purposes or are convenience wrappers that duplicate existing functionality. Examples include list_all_* vs list_* (pagination variants), materialize_element vs materialize_and_wait, export_workbook vs export_and_download, bulk_assign_team_members vs update_team_members, and update_user_attribute_for_users vs delete_user_attribute_for_user. These near-duplicates create significant ambiguity about which tool to use.
Naming Consistency4/5
Naming follows a consistent sigma_ prefix and snake_case verb_noun pattern (e.g., list_workbooks, get_connection, create_report). Minor deviations exist: sigma_api_capabilities and sigma_formula_pitfalls are noun phrases, and compound verbs like materialize_and_wait and export_and_download break the simple verb_noun structure. Overall, patterns are predictable and readable.
Tool Count1/5
With 155 tools, the server massively exceeds practical limits for agent tool selection. Many tools are redundant wrappers, pagination variants, or meta utilities (e.g., list_all_workbooks, materialize_and_wait, search_docs). This creates cognitive overload and makes it difficult for an agent to choose the correct tool efficiently.
Completeness4/5
The server provides highly extensive lifecycle coverage for most resources: workbooks, reports, data models, connections, members, teams, workspaces, deployments, tags, and user attributes all have comprehensive CRUD and auxiliary operations. Minor gaps include dedicated delete operations for workbooks/reports (workaround via sigma_delete_file) and deletion of report schedules, but these are easily circumvented.
Average 3.5/5 across 155 of 155 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on August 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds no behavioral details such as pagination, return format, or implications of openWorldHint=true. The description contributes nothing beyond what the annotations already convey, so transparency 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but its brevity is under-specification rather than effective conciseness. It restates the tool name and omits essential information, making the description unhelpfully short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple input schema and an output schema, the description is incomplete. It does not define what a 'page' is, how workbook_id is used, or how this tool relates to siblings like sigma_list_workbook_page_elements. The presence of openWorldHint and many similar tools suggests more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, workbook_id, with no description (0% coverage). The tool description does not mention this parameter or add any meaning, such as format or constraints. Although the parameter name is self-explanatory, the description fails to enhance understanding for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List pages in a workbook' is a direct restatement of the tool name 'sigma_list_workbook_pages'. It does not add any specific context about what pages are or how this tool differs from siblings like sigma_list_workbook_page_elements, so it provides no meaningful differentiation beyond a synonym for the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It fails to mention any conditions, exclusions, or related tools, leaving the agent without criteria to choose between this and the many similar listing tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations indicate the tool is not read-only and not destructive, but the description doesn't disclose side effects, return values, or any requirements. It fails to leverage the opportunity to explain what 'create a report' actually entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is extremely concise, but this is under-specification rather than effective conciseness. The single sentence does not earn its place because it conveys almost no useful information for tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex, undocumented 'body' object and an output schema, this description is completely inadequate. There are no examples, no prerequisites, no description of the report object structure, and no differentiation from sibling tools. The agent cannot confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'body' parameter with an arbitrary object (additionalProperties true) and 0% schema description coverage. The description 'Create a report.' provides no information about what fields are expected in 'body', so the agent is left completely unguided about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a report.' clearly states the action (create) and resource (report). It is not a tautology, but it does not distinguish this from sibling tools like sigma_create_workbook or sigma_convert_workbook_to_report, which are also creation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or alternatives. The description is too brief to convey any usage context, leaving the agent without information on how this differs from other report-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a write operation (readOnlyHint false), and the description simply restates 'create.' It adds no additional context about side effects, permissions, idempotency, or failure behavior. The openWorldHint suggests potential side effects not disclosed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, efficient and front-loaded. It earns high marks for structure, though it may be too terse given the tool's complexity, which is a completeness concern rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has nested object parameters, an openWorldHint, and no parameter descriptions. A one-sentence description is wholly inadequate for an agent to construct a valid request, as input semantics are entirely unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description completely omits any explanation of the 'name' or 'body' parameters. The 'body' parameter is an open object with additionalProperties allowed, yet the agent receives no guidance on its required structure or content, making it nearly impossible to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a deployment policy' clearly states the action (create) and the target resource (deployment policy), distinguishing it from list/get/archive operations. However, it does not clarify what a deployment policy is or how it differs from other create actions like sigma_create_source_swap_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as sigma_list_deployments or sigma_create_source_swap_policy. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. It does not mention output format, required permissions, or any constraints, despite the readOnlyHint and openWorldHint annotations being present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified; it lacks any detail beyond the basic purpose, making it minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description is too sparse to be considered complete. It does not explain usage context, parameter semantics, or behavior that would help an agent select and invoke this tool among the many report-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The report_id parameter is not described in the tool description. With 0% schema description coverage, the description fails to clarify the parameter's meaning or how to obtain a valid report ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (Get) and the resource (report metadata), making the core purpose clear. However, it does not differentiate this from sibling tools like sigma_list_reports or sigma_get_workbook, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. The description only states the basic action, with no context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the basic 'swap' operation. Annotations already indicate non-read-only and non-destructive, but nothing is disclosed about effects on dependent elements, required permissions, reversibility, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, making it concise and front-loaded. However, it is under-specified for a tool with an open-ended body schema and no additional guidance, so brevity borders on insufficiency rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 tool involves an unstructured 'body' object and swapping semantics that are not explained. The one-line description does not provide enough context for correct invocation, especially with numerous sibling swap tools and related operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters with zero description coverage; the body parameter is an open additionalProperties object with no explanation, and the description never mentions how to construct or use either parameter. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific action verb 'Swap' and identifies the resource as 'data sources for a data model,' which clearly distinguishes it from sibling swap tools targeting workbooks, reports, or templates. However, it does not elaborate on the scope or nuances of what swapping entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_swap_workbook_sources or sigma_swap_report_sources. No exclusions, prerequisites, or situational context are provided, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds no additional behavioral context, such as whether the returned details include sensitive information, whether the connection_id must refer to an existing connection, or any rate limits. It merely restates the basic retrieval action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is succinct, but it is under-specified rather than appropriately concise. It contains minimal information beyond what the tool name conveys, offering little value to an agent deciding whether to invoke it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description could still be adequate with more context. It lacks differentiation from sibling tools, does not clarify what 'details' includes, and omits usage guidance. The presence of an output schema partially covers return values, but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter, connection_id, with zero description coverage. The description only implies that the parameter identifies the specific connection ('for a specific connection') but does not explain its format, how to obtain it, or any constraints. This fails to compensate for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as retrieving details for a specific connection, using the verb 'Get' and the resource 'connection'. It indicates a single resource by ID, which distinguishes it from listing all connections. However, it does not explicitly differentiate from sibling tools like sigma_list_connections or sigma_test_connection, 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.
Usage Guidelines2/5
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 does not mention that it is for retrieving a single connection by ID, nor does it contrast with listing connections or testing connections. There is no context about prerequisites or when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which inform the agent about safety and openness. The description adds no behavioral context beyond that, such as what 'metadata' includes or how the open-world hint might affect results. It fails to add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it borders on under-specification. It lacks the structure needed to effectively guide tool selection, and while the single sentence is front-loaded, it does not provide sufficient detail to justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations present, the description need not explain return values, but it must disambiguate from closely related siblings like sigma_get_data_model_spec. The current description does not clarify what 'metadata' entails or how it differs from other data model retrieval tools, making it incomplete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the required data_model_id parameter or explain how to obtain its value. The parameter name is self-explanatory, but the description provides no additional semantic context, leaving the agent without guidance on what constitutes a valid ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('data model metadata'). However, it does not distinguish itself from the sibling tool sigma_get_data_model_spec, which likely retrieves related data model information, leaving ambiguity about the specific scope of 'metadata'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like sigma_list_data_models or sigma_get_data_model_spec. There is no mention of prerequisites, recommended contexts, or exclusions, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description aligns with. However, the description adds nothing beyond the bare action—no mention of what 'details' include, whether member information is returned, or any rate/permission caveats. Minimal extra value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It does not waste words, but it also fails to provide useful context that would make it 'appropriately sized' for a tool with many siblings and a bare schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While this is a simple read-only get operation with an output schema, the description omits any disambiguation from sigma_list_teams, does not explain what fields are returned, and lacks prerequisites or error behavior. The presence of an output schema reduces the need to describe return values, but the lack of usage context and parameter guidance leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 required parameter, team_id, with no description (schema description coverage 0%). The description does not explain the format or meaning of team_id beyond its name. For a single self-explanatory parameter, the lack of compensation is somewhat mitigated, but the description still adds no semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Get team details' for a specific team. It is distinct from sibling tools like sigma_list_teams, which lists all teams, but the description does not explicitly contrast them or mention the team_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sigma_list_teams is for listing all teams or that other team-related tools exist for modifications. The usage context is implied only by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds no extra behavioral context. It does not describe what 'metadata' includes, whether the workbook must exist, or any access requirements. The description is essentially a restatement of the tool name with no added behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose. There is no filler or unnecessary detail. However, it is under-specified, which slightly reduces the score from 5, but for a simple get operation this length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and annotations cover safety, the description lacks key contextual information. It does not explain how to use the workbook_id parameter, provide any usage guidance, or clarify what metadata is returned. For a one-parameter tool, it is minimally viable but leaves notable gaps in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, workbook_id, but no description in the schema (coverage 0%). The description does not mention the parameter at all, leaving the agent to guess what workbook_id should be or how to obtain it. This is a critical gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get workbook metadata' – a specific verb and resource. It is easy to understand the tool's function, but it does not differentiate from sibling tools like sigma_list_workbooks or sigma_get_workbook_version_history, so it loses a point for not distinguishing among alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling tools. There is no mention of prerequisites, context, or alternatives. It is simply a bare statement of the operation, so usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only and non-destructive behavior, so the description does not need to repeat that. However, it claims to list 'all reports' while the only parameter is a 'limit' with a default of 200, suggesting the result may be truncated. This potential discrepancy is not disclosed, and no extra behavioral context is added 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and resource. It is free of unnecessary words and appropriately sized for a simple listing tool. However, it is slightly under-specified due to the missing parameter and alternative guidance, though that is not a conciseness issue per se.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is not complete in context. Given the output schema exists, return values are covered, but the description fails to address the 'limit' parameter and the existence of the sibling 'sigma_list_all_reports'. The claim 'all reports' without qualification is misleading, and the tool's relationship to the sibling tool is unclear, leaving gaps for an agent deciding between them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'limit', but the description does not mention it at all. With 0% schema description coverage, the description fails to compensate by explaining the purpose or effect of 'limit'. The agent cannot determine how to use or adjust the limit parameter from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'reports', with scope 'all in the organization'. It distinguishes from list_workbooks and other resources, but does not differentiate from the sibling tool 'sigma_list_all_reports', which likely has similar or broader behavior. This missing differentiation prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling 'sigma_list_all_reports'. There is no mention of pagination, limits, or exclusions. The usage is only implied (to list reports) but not contextualized against other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds no further behavioral context. It does not disclose whether parent_id must reference a folder or workspace, whether the folder is created immediately, or any side effects like permission checks. The description simply restates the operation without elaborating on behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, making it easy to read and front-loaded. It earns a high score for brevity, even though it lacks informational depth, because the conciseness dimension rewards minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no schema descriptions, the description is too sparse to be complete. It omits necessary context about the parent_id parameter and the expected folder structure, leaving users to guess how to invoke the tool correctly. The presence of an output schema does not mitigate the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its parameters (name and parent_id), and the description fails to explain their semantics. 'Create a folder.' provides no hint about what parent_id refers to or any constraints on the name. The description does not compensate for the schema's lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a folder.' clearly identifies the action (create) and the resource (folder), distinguishing it from sibling tools like sigma_create_workspace or sigma_create_workbook. However, it lacks any qualifiers about the folder type or location, making it generic but still unambiguous in the Sigma context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention typical use cases, prerequisites (e.g., existing parent folder), or contrast with sigma_create_workspace or other create operations. Users are left to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not bear the full burden, but it adds no additional behavioral context such as required permissions, scheduling cadence, or side effects. There is no contradiction with annotations, but the description is too sparse to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and does not earn its place. It lacks critical details about the request body or schedule configuration, so conciseness here is a detriment rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested object body and has zero schema description coverage, yet the description provides no context about how to structure the schedule, what fields are required, or what happens after creation. Even with an output schema present, the description is wholly inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not compensate. It mentions a 'report' but does not explain the 'body' object, which is open-ended (additionalProperties: true) and likely contains critical schedule settings. The description adds no semantic meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a scheduled export for a report' uses a specific verb and resource, clearly distinguishing it from sibling tools like sigma_list_report_schedules (listing schedules) and sigma_export_report (one-time export). It unambiguously identifies the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to create a schedule), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It could benefit from noting that this is for report schedules specifically, versus workbook schedules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false) and not destructive. The description adds no new behavioral context such as side effects, idempotency, uniqueness constraints, or required permissions. There is no contradiction with the annotations, but the description is redundant with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the purpose. There is no wasted wording or unnecessary structure. It is front-loaded and appropriately sized for a simple create operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only two parameters and an output schema is present, the description is too minimal to be contextually complete. It does not mention naming conventions, uniqueness requirements, required permissions, or how this creation relates to team members or workspace context. The agent receives only the most basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 'name' or 'description' parameters. The schema itself gives field names and types, but the description does not add any meaning beyond those labels. With low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: create a new team. It uses a specific verb+resource and distinguishes from sibling tools like sigma_delete_team, sigma_list_teams, and sigma_get_team. However, it gives no additional detail about team properties or the creation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives or about prerequisites such as permissions or existing workspace context. The description is a bare imperative sentence and does not help the agent decide between creation and other team-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds no behavioral context about what happens after export (e.g., returns content, creates a file, triggers a download). It does not mention permissions or side effects, leaving the agent to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the action. The list of formats is directly useful. However, it reads more like a parameter note than a well-structured description, and it sacrifices necessary details for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with only two parameters, the description is still incomplete. It fails to clarify the return type or output behavior (critical for an export), lacks guidance on how to specify the report, and offers no context about alternative tools. The presence of an output schema helps but does not cover usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It lists the allowed format values ('pdf', 'png', 'csv', 'xlsx'), which helps, but provides no explanation of what report_id refers to or how it should be formatted. The parameter meaning is only partially addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Export a report' with a specific resource. It does not differentiate from sibling tools like sigma_export_workbook or sigma_export_and_download, 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.
Usage Guidelines2/5
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. There is no mention of prerequisites, context, or situations where another export tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no context beyond the tool name, such as job state semantics, error conditions, or that it may be used for polling. Thus it provides minimal additional behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the verb and object directly, making it very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 description lacks context about the materialization lifecycle—how jobs are created, when to poll them, and what statuses might appear. This makes it incomplete for an agent to know when and why to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two required parameters. The description does not compensate by explaining what job_id and workbook_id refer to or how they relate to a materialization job. Parameter meanings must be inferred solely from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('status of a materialization job'), clearly indicating a read operation. It does not explicitly distinguish from sibling materialization tools like sigma_materialize_element or sigma_materialize_and_wait, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 it should be used after creating a materialization job, nor does it reference polling patterns or alternatives like sigma_materialize_and_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, which cover the safety profile. The description adds no additional behavioral context (e.g., pagination, ordering, response format). It simply restates the listing action without enriching 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the action and resource clearly. However, it is somewhat under-specified, which prevents a perfect score, but it is appropriately concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown) and one required parameter, but the description fails to explain what constitutes an 'element' in a data model. It does not mention the return structure, whether it includes metadata, or how it differs from listing columns or lineage. This is a significant gap for a tool with minimal annotations and no parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The only parameter, data_model_id, is not explained beyond its name, and the description does not clarify what data model ID to use or how to obtain it. This is insufficient given the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'elements in a data model', which distinguishes it from sibling tools like list_data_model_columns or list_workbook_elements. However, it does not clarify what 'elements' means in this context, so it is clear but not fully detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_data_model_columns or sigma_list_data_model_lineage. The description does not provide any context on prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior, so the bar for additional disclosure is lower. However, the description says 'all workspaces' while the schema includes a limit parameter defaulting to 200, suggesting results may be capped—this nuance is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key verb and resource. There is no wasted wording, though it sacrifices meaningful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema likely covers return values, the description omits important operational details such as the limit parameter's effect and the meaning of 'all' when a limit exists. For a list tool, this is a material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds nothing about the 'limit' parameter. The schema merely labels it 'Limit' with a default, leaving the agent to infer its meaning without support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List all workspaces') which clearly identifies the operation. It doesn't explicitly differentiate from sibling list tools, but the resource name itself provides that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any context about pagination or the limit parameter. The description leaves the calling conditions entirely unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a non-read-only, possibly side-effect operation, but the description adds little about the actual behavior. It does not mention that this likely starts an asynchronous job, what the response contains, or whether it requires any special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and avoids unnecessary fluff. However, the wording is imprecise ('if needed') and could be improved without adding length, so it is still concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but the description does not explain what is returned. It also fails to mention how this action relates to other materialization tools or what follow-up steps are needed. For a trigger operation, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions elementId with the phrase 'if needed', which contradicts the schema's required field. workbook_id is entirely unaddressed. Given the 0% schema description coverage, this is inadequate and potentially misleading for parameter handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger materialization') and the resource ('for a workbook'), but it omits the element focus and misleadingly suggests elementId is optional when the schema marks it required. It does not differentiate from sibling tools like sigma_materialize_and_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_materialize_and_wait, sigma_get_materialization_job, or how the result of this trigger should be consumed. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description does not disclose any additional behavioral traits such as network requests, failure modes, or side effects. It adds no detail beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise and front-loaded, containing no filler. It earns its place but is too sparse to provide substantive guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While a simple one-parameter tool with an output schema might require less description, the current text is insufficiently contextual: it does not clarify what 'connectivity' means, when to use it, or what success/failure looks like. Given sibling complexity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required string parameter `connection_id` with no description. The description does not explain the parameter's meaning, format, or how to obtain a valid ID, despite the 0% schema-description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Test' with the resource 'connection', clearly indicating a connectivity check. This distinguishes it from sibling tools like sigma_list_connections and sigma_get_connection, though it does not specify what testing entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_sync_connection or sigma_get_connection. The description lacks context for deciding between testing and other connection operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds only the HTTP method and endpoint, but no behavioral details such as whether the change is permanent, whether email uniqueness is enforced, or any permission requirements. Annotations indicate it's not read-only and not destructive, but the description adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and includes the relevant endpoint. Every word is purposeful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation with no output schema details shown, the description is too sparse. It lacks context about side effects, alternative tools, or necessary conditions, making it minimally complete for a simple tool but inadequate for an agent to fully understand the operation's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameter meaning, but it only implies member_id and new_email from context. It does not specify format, validation, or constraints, relying solely on the self-explanatory parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change a member's email address') and the specific resource, distinguishing it from more generic member operations like sigma_update_member. However, it does not explicitly differentiate from sibling tools, 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.
Usage Guidelines2/5
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, nor any prerequisites or postconditions. It simply states the operation without context, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'restore' aligns with mutation. However, the description adds no extra behavioral context such as reversibility, effects on current version, or permission requirements. It fails to go beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that earns its place by stating the core action. It avoids fluff, but it is arguably too sparse, though the conciseness itself is solid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two required parameters and no output schema details, the description is incomplete. It does not explain the restore behavior, potential impacts, or how parameters relate, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameters 'workbook_id' or 'version' beyond their raw schema titles. The description must compensate for the lack of schema documentation but does not, leaving parameter semantics entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restore a workbook to a previous version' clearly identifies the action (restore) and target resource (workbook version), distinguishing it from siblings like get_workbook_version_history. It is specific 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.
Usage Guidelines2/5
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, no exclusions, and no prerequisites. Usage is only implied by the name and one-line purpose, with no explicit context or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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). However, the description adds no behavioral detail beyond that, such as whether the template overwrites existing ones, permission requirements, or side effects. This is minimal value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and directly front-loaded with the core action. It is appropriately short for the simplicity of the task, though it could include more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential context about preconditions, parameter dependencies, or any caveats such as folder placement or naming defaults. An agent would need to infer how folder_id and name are used, making the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for documenting the three parameters (workbook_id, folder_id, name), but it does not mention any of them. The parameter names are somewhat self-explanatory, yet the description adds nothing to clarify their usage, optionality, or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the resource ('a workbook as a reusable template'), which distinguishes it from sibling tools like create_workbook_from_template or list_templates. The verb+resource combination leaves little ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention any prerequisites or exclusions. While the purpose implies a use case, there is no explicit context to help an agent decide between this and related template tools like list_templates or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate `readOnlyHint: false` and `destructiveHint: false`, so the description adds no new behavioral context. It does not mention idempotency, duplicate bookmark behavior, required permissions, or success/failure semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler. It front-loads the action and object, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with a nested, open-ended `body` parameter, yet the description provides no details about bookmark structure or use cases. The output schema exists, but input ambiguity remains significant for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not compensate. It mentions 'a workbook' but never references `workbook_id` or `body`, leaving the `body` object (which has `additionalProperties: true`) completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and a clear resource ('a bookmark to a workbook'), immediately conveying the tool's function. It is easily distinguished from sibling `sigma_list_workbook_bookmarks`, which is the listing counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of required fields or context. The existence of sibling `sigma_list_workbook_bookmarks` implies add-vs-list usage, but no explicit comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the obvious 'create' action, which is already implied by the tool name. It fails to disclose any behavioral details such as idempotency, unique constraints, or permission requirements, and annotations are minimal (readOnlyHint false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with two parameters and no behavioral details, the description is too sparse. It does not explain the optional 'body' parameter or any constraints, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (name, body) with 0% description coverage. The description does not explain the 'body' parameter or clarify that 'name' is required, leaving parameters semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'tenant organization', clearly identifying the tool's function. It distinguishes from sibling tools like sigma_create_team and sigma_create_workspace by the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, nor any prerequisites or exclusions. It only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Create a new workspace' without disclosing any behavioral traits such as side effects, error conditions, or authentication requirements. The annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds no context beyond these, so the agent learns nothing additional about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'Create a new workspace,' with no unnecessary words. It is concise, though it sacrifices detail for other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with one parameter, the description may be minimally adequate, but it lacks important context such as the existence of an output schema, side effects indicated by openWorldHint=true, or guidance on what happens after creation. It is incomplete for an AI agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'name' with no description, and the description does not mention parameters at all. With 0% schema description coverage, the description fails to compensate by explaining what 'name' means or any constraints like uniqueness or length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' and identifies the resource 'workspace', clearly distinguishing from sibling tools like sigma_list_workspaces, sigma_get_workspace, and sigma_delete_workspace. It states exactly 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.
Usage Guidelines2/5
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 does not mention prerequisites, such as required permissions or uniqueness of the workspace name, nor does it reference related tools like sigma_list_workspaces for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no additional behavioral context, such as requirements, failure modes, or performance characteristics. It simply restates what the tool does without elaborating on edge cases like elements without SQL queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded and easy to parse, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get operation with two obvious parameters and an output schema, the description is adequate but not thorough. It lacks any usage context or differentiation from similar tools, and does not mention potential limitations, making it minimally complete rather than richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameters beyond implying that element_id and workbook_id identify the element and workbook. The parameter titles already convey this, so the description adds minimal semantic value and fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the generated SQL query for a specific element in a workbook, using a specific verb and resource. However, it does not differentiate from sibling tools like sigma_list_workbook_queries or sigma_get_element_columns, so it loses a point for lacking explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 gives no context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, which align with the 'Get' verb. The description does not contradict these annotations, but it also adds no additional behavioral context beyond the basic read operation. No error handling, return format, or special conditions are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 with the action and resource, making it immediately scannable and easy to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, read-only, output schema present), the description is minimally sufficient. However, it does not mention what 'details' includes, nor does it clarify potential ambiguity (e.g., whether this refers to a standard template or a shared template). The output schema and annotations compensate for some gaps, leaving the description just adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full responsibility for explaining the parameter. It does not elaborate on what template_id refers to, how to obtain it, or any format expectations. The schema only provides the title 'Template Id', which the description does not enrich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and clearly identifies the resource as 'template details'. This distinguishes it from other get_* tools (e.g., get_workbook, get_connection) since it explicitly targets templates. However, the word 'details' is vague and does not specify exactly what information is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or contextual cues. The description simply states the action without explaining the appropriate scenario for using sigma_get_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. However, the description adds no behavioral context beyond the annotations, such as return value semantics, auth requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or redundancy. Every word earns its place, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with an output schema and annotations available, so the description need not explain return values. However, 'workspace details' is vague about what is included, and the description lacks context that would help an agent distinguish it from similar workspace-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, workspace_id, with zero description coverage. The tool description does not explain the parameter or its role beyond the self-explanatory name, leaving low-coverage compensation absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get workspace details' clearly states the verb and resource, indicating the tool retrieves information about a specific workspace. It lacks scope or differentiation from other get tools, 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.
Usage Guidelines2/5
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 such as sigma_list_workspaces or sigma_get_workbook. The description offers 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, idempotent, non-destructive behavior, but the description adds no further context about side effects, idempotency implications, permission overwrites, or required authentication. It only restates the action and allowed values, failing to disclose behavioral details beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ultra-compact, front-loading the core purpose in the first sentence and using a concise list for parameter values. No filler words or redundant restatements; however, it is arguably too terse to cover all necessary details, but for conciseness this is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 required parameters, zero schema descriptions, and no output schema content provided, the description covers only a fraction of the necessary context. It omits the relationship between grantee_id and grant_type, acceptable inputs for workbook_id, and any behavioral outcomes beyond granting. The existence of an output schema reduces the need to describe return values, but the overall tool context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for missing parameter details. It explains allowed values for grant_type and permission, but leaves workbook_id and grantee_id undefined, and does not clarify that grantee_id semantics depend on grant_type (member vs team). This is partial compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure ('Grant access to a workbook') and explicitly distinguishes from sibling tools like sigma_grant_workspace_access by targeting workbooks. It also lists valid values for grant_type and permission, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives (e.g., sigma_list_workbook_grants for viewing grants, sigma_grant_workspace_access for workspace-level grants) or any prerequisites like the existence of the workbook or grantee. The allowed values hint at usage but are primarily parameter constraints, not contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds no additional behavioral context. It does not explain what happens on repeated grants, whether existing permissions are overwritten, or any side effects, missing the opportunity to complement the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no filler text. The parameter value list is directly useful and structured, though it could be expanded slightly without becoming verbose. It earns high marks for brevity and layout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four required parameters and an output schema, the description is too sparse. It lacks context on the effect of the grant, any prerequisites, or how this relates to other permission tools. The output schema covers return values, but the operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the allowed values for grant_type and permission, which adds meaning beyond the bare schema. However, workspace_id and grantee_id are left entirely unexplained, and with 0% schema coverage, the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Grant workspace access' with a specific verb and resource, making it clear what the tool does. It does not explicitly distinguish it from sibling tools like sigma_grant_workbook_access, but the workspace focus is implicit in the name and description, giving it adequate purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of prerequisites, and no exclusions. It simply states the action and parameter values, leaving the agent without context for selecting this tool among many grant-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no additional behavioral context. It does not mention pagination, ordering, or any other behavioral trait beyond the straightforward 'List' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and it is front-loaded with the action. However, it is extremely terse and omits contextual details that could aid tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the domain-specific term 'materialization schedules' and the existence of closely related sibling tools (e.g., sigma_list_workbook_schedules), the description is not sufficiently complete. It lacks necessary context to disambiguate from similar operations, despite having an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, workbook_id, with no description (0% coverage). The description's phrase 'for a workbook' adds little beyond what the parameter name already implies, and it does not clarify the expected format or meaning of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('materialization schedules for a workbook'). It is specific enough to distinguish from sibling tools like sigma_list_workbook_schedules, which deals with a different schedule type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools such as sigma_list_workbook_schedules or sigma_get_materialization_job. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds no behavioral context beyond what the name implies. It does not mention pagination, return format, or whether hidden elements are included, which would be useful for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and well-structured: a single, clear sentence with no redundant words. It front-loads the purpose without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is minimally adequate. However, it does not clarify what 'elements' means in the context of a report, which could be ambiguous given the many sibling list tools. It would benefit from a brief elaboration on the type of elements returned or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the report_id parameter (0% coverage). The description only implies that report_id identifies the report, but does not explain how to obtain it, its format, or any constraints. This minimal compensation is insufficient for an undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'list' and specifies the resource as 'elements in a report', clearly distinguishing it from sibling tools like sigma_list_workbook_elements and sigma_list_data_model_elements. It lacks additional scope qualifiers (e.g., 'all' or 'page') that might further refine its meaning, but it is still specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention any prerequisites, usage context, or reference to similar tools such as sigma_list_workbook_page_elements, making it hard for an agent to decide when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is known. However, the description adds no extra behavioral context such as pagination, filtering scope, or how grants are represented beyond what the output schema might show.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'List', and contains zero fluff. It is perfectly concise for the purpose it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description lacks usage guidelines and parameter details. Given the large sibling list with similar grant-listing tools, the description is too thin to fully orient an agent and ensure correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (workbook_id) with no description, and the overall schema description coverage is 0%. The description does not explain what 'workbook_id' is, how to obtain it, or any format requirements, leaving the agent without necessary parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List permission grants on a workbook.' clearly states the action (list) and the resource (permission grants on a workbook). It distinguishes from sibling tools like sigma_list_workspace_grants and sigma_list_connection_grants by specifying 'workbook' as the object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as sigma_list_grants or sigma_list_workspace_grants. There is no mention of 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), but the description adds no further behavioral context. It does not disclose side effects, required permissions, body structure, or success/failure behavior, which is notable for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler and is front-loaded with the action and object. However, its brevity comes at the cost of omitting critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with an open nested body and no parameter documentation, the description is incomplete. It fails to define what a source swap policy is, what the body should contain, and how it differs from manual source-swapping tools. The existing output schema does compensate for return values, but not for input requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'body' is an open object with no schema description (0% coverage). The description does not mention the body or explain what fields should be included, leaving the agent fully uninformed about how to construct the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'source swap policy' and adds context 'for automated deployments.' This clearly distinguishes it from related siblings like sigma_list_source_swap_policies and sigma_get_source_swap_policy, which are read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint of when to use the tool via 'for automated deployments,' but it does not explicitly compare with alternative swap tools such as sigma_swap_workbook_sources or sigma_swap_data_model_sources. No exclusions or alternative guidance are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context (e.g., what happens if the policy does not exist, or whether pagination is involved). It aligns with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to the core purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema exists), but the description provides no context about what a 'deployment policy' is, how to find policy IDs, or when to use this against related tools like sigma_get_source_swap_policy. It lacks any navigational guidance, making it incomplete for an agent exploring the toolkit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (policy_id) with 0% description coverage. The description does not explain the parameter's meaning, format, or how to obtain a valid value. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('deployment policy'), clearly identifying the operation. It distinguishes from sibling 'list' tools like sigma_list_deployments by implying a single-item fetch, though it doesn't explicitly contrast with similar getters like sigma_get_tenant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. There is no mention of prerequisites (e.g., needing a valid policy_id from sigma_list_deployments) or exclusions. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to 'List all tenant organizations', which directly contradicts the openWorldHint annotation indicating results may not be exhaustive. Aside from this, it adds no behavioral detail beyond what annotations already provide, such as pagination, permissions, or result set limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, with a parenthetical context qualifier. Every word earns its place, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, output schema present, read-only annotations), a minimal description is mostly sufficient. However, the openWorldHint contradiction leaves ambiguity about whether the result set is complete, and the sibling sigma_list_tenants_paginated is not mentioned, making the description less complete than it could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the baseline for zero-parameter tools, a score of 4 is appropriate because there are no parameter semantics for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('tenant organizations'), with a context qualifier ('for multi-tenant deployments'). It clearly states what the tool does, but it does not explicitly differentiate it from the sibling tool sigma_list_tenants_paginated, even though 'all' hints at a non-paginated variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_tenants_paginated or sigma_get_tenant. The phrase 'for multi-tenant deployments' offers some context but no exclusions, prerequisites, or explicit alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description simply says 'List', which aligns with those hints without adding new behavioral context. It does not disclose any rate limits, pagination behavior, or specific restrictions beyond the examples of element types, which are more about scope than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with 11 words, immediately front-loading the action and resource. Every word adds value, and it avoids any redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations and an output schema, the description is largely sufficient. It conveys the primary purpose and gives examples of element types. However, the lack of usage guidance and parameter explanation prevents a perfect score, though the output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter workbook_id, and the description does not compensate by explaining this parameter. While the parameter name is somewhat self-explanatory, the description provides no additional meaning or format details, failing to fulfill the requirement to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all elements (tables, charts, controls, etc.) in a workbook.' It uses a specific verb ('List') and identifies the resource ('elements') and scope ('in a workbook'). However, it does not explicitly differentiate from close siblings like sigma_list_workbook_page_elements or sigma_list_workbook_controls, relying on the 'etc.' to imply broad scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no mentions of exclusions, prerequisites, or references to sibling tools. The usage is only implied by the action of listing elements, which is not enough given the many similar list tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false. The description adds no extra behavioral context such as pagination, filtering, or what constitutes 'data sources'. It merely restates the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is front-loaded and concise, suitable for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and strong annotations reduces the need to explain return values. However, the description lacks any usage context or parameter elaboration, making it minimally adequate but with clear gaps in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the only parameter workbook_id, and the description does not explain its meaning, format, or constraints. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'data sources used by a workbook', clearly distinguishing it from siblings like sigma_list_workbooks and sigma_list_workbook_queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any mention of alternatives. The description is purely definitional and does not provide contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations indicate readOnlyHint=false, so the mutation is expected, but the description does not disclose any side effects, permissions, or additional behaviors beyond the basic creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and front-loaded, conveying the core function immediately without wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema has 3 parameters with zero documentation and there is an output schema, the description is too sparse. It does not explain the return value (though output schema exists), nor does it cover the 'description' parameter. The tool is simple, but the description leaves gaps about the creation context and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameters. It only hints at 'folder' (likely folder_id) but does not clarify the meaning of 'name' or 'description', nor does it mention that folder_id is required. The description fails to illuminate any parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (workbook), and the qualifier (empty) and location (in a folder). It distinguishes from sibling tools like sigma_create_workbook_from_template by specifying 'empty', and from duplicate by indicating a new creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any exclusions or alternative tools, leaving the decision to the agent based solely on the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. The description adds no extra behavioral context such as permissions or response details, but the annotation presence lowers the bar. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. It efficiently states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema and read-only annotations, the description is mostly sufficient for a simple get operation. However, the existence of sibling sigma_get_tenant_scoped_info creates ambiguity that a richer usage note would resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 additional meaning about tenant_id. While the parameter name and title are self-explanatory, the description does not compensate for the missing schema documentation, so it adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('tenant organization details'), making the tool's purpose clear. However, it doesn't explicitly differentiate from sibling tools like sigma_get_tenant_scoped_info or sigma_list_tenants, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. With many sibling tools related to tenants, this lack of context is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read. The description adds no extra behavioral context such as whether grants are returned as a list of user/group permissions, whether inherited grants are included, or any pagination implications. It merely restates the tool's purpose without enriching understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, stating the action, resource, and scope compactly. This is appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set, the description lacks critical context: it does not indicate the relationship to sigma_add_connection_grant, how to obtain a valid connection_id, or any caveats about listing grants. An output schema exists, which helps with return values, but the one-line description is too sparse for confident selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, connection_id, with no description (0% coverage). The description's phrase 'on a connection' implicitly ties connection_id to the target, but it does not explain the expected format, how to find the connection ID, or any constraints. Minimal compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'permission grants on a connection'. It distinguishes from sibling tools like sigma_list_connections (which lists connections themselves) and sigma_add_connection_grant (which creates grants), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 relative to alternatives such as sigma_add_connection_grant or sigma_get_connection. There is no mention of using connection_id from sigma_list_connections, nor any exclusions or situational context. The only implied usage is by the name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a behavioral detail about summary_only=true producing a concise response, which is beyond the schema. However, it does not disclose limit behavior, pagination, or what the response contains, so additional transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's core function, the second offers a practical usage tip. No redundant words or filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of annotations and an output schema, the description covers the primary listing purpose. However, it fails to clarify the role of the limit parameter, does not distinguish itself from the similarly named sibling sigma_list_all_data_models, and provides no information about pagination or result format, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 purpose of summary_only (concise token-efficient response) but completely omits the 'limit' parameter, leaving its meaning and behavior undocumented. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all data models') and scope ('in the organization'). However, it does not distinguish this from the sibling tool 'sigma_list_all_data_models', which likely has a similar purpose, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is a parameter tip ('Pass summary_only=True for concise token-efficient response'). No context is provided about when to use this tool versus related listing tools like sigma_list_data_model_elements or sigma_list_all_data_models, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the context that summary_only yields a token-efficient response, but it does not disclose pagination behavior or other details. This adds some value but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a clear purpose and a specific usage tip. It 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with output schema present, the description is adequate but has gaps. It does not clarify the semantics of the limit parameter and does not differentiate from the sibling 'sigma_list_all_members', so it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 purpose of summary_only but says nothing about the 'limit' parameter, which remains ambiguous. With two parameters and only one explained, the description only partially fulfills the compensation requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all members in the organization', providing a specific verb and resource. However, it does not distinguish this tool from the very similar sibling 'sigma_list_all_members', so it lacks sibling differentiation that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'sigma_list_team_members' or 'sigma_list_all_members'. The only usage advice is 'Pass summary_only=True for concise token-efficient response', which is a parameter optimization tip, not a when-to-use or when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a minor behavioral detail ('recently recorded') but does not explain the time window, pagination, or filtering behavior beyond the parameter names. This adds some value but leaves several behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main sentence is concise and front-loaded, stating the tool's purpose directly. However, the appended 'read_only_hint: True' repeats the annotations verbatim, adding no value and reducing overall structure quality. It is not as clean as it could be, but it is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a very simple read-only event list, but it omits crucial usage details such as how to filter by event_type or control the result count with limit. An output schema exists, so return format is covered, but the description fails to explain the parameters or any pagination behavior, making it insufficient for an agent to use the tool correctly without additional guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (no descriptions for 'limit' or 'event_type'), and the description makes no mention of either parameter. The parameter names are reasonably self-explanatory, but the description does not compensate for the lack of schema-level detail, so the agent receives no additional semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'List recently recorded incoming Sigma webhook events.' The verb 'List' and resource 'webhook events' are specific, and the absence of any other webhook-related sibling tools makes it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's usage—to view recent webhook events—but provides no explicit guidance on when to use this tool over alternatives or any exclusions. Given the many sibling list tools, more specific direction would be helpful, but the resource-specific naming offers some implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description isn't needed for safety. It adds the behavioral detail that summary_only produces a concise, token-efficient response, which is modest additional context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant words. It is appropriately front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 and safety annotations, the description is minimally adequate. However, it omits pagination behavior and fails to clarify the overlap with sigma_list_all_teams, leaving the agent uncertain about when to use which tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description must explain parameters. It explains summary_only's effect but does not mention limit, pagination, or how to retrieve all teams beyond the default 200. This leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'teams,' clearly indicating the tool's function. However, it does not differentiate from the sibling tool sigma_list_all_teams, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives like sigma_list_all_teams or sigma_get_team. The only usage tip ('Pass summary_only=True') addresses a parameter, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait of polling until complete or timeout, which goes beyond the annotations (readOnlyHint: false, destructiveHint: false). However, it doesn't disclose what happens on timeout, whether the job is left running, or if there are side effects beyond the initial trigger. Given the annotations already indicate a non-read-only operation, the added value is moderate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and result. There is no filler or redundant information, and every word contributes to the meaning. It is appropriately sized for a simple tool summary, though brevity may sacrifice completeness in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool that performs a multi-step operation (trigger + poll). It omits how parameters map to behavior, what constitutes a timeout, and how the tool handles errors or partial results. Even with an output schema present, the description lacks critical usage context, leaving an agent to make assumptions about timeout semantics and job lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter descriptions in the tool description, the meaning of element_id, workbook_id, and timeout_seconds is left entirely to inference from their names. The description only mentions 'timeout' vaguely, which could map to timeout_seconds, but it doesn't explain the other parameters or the relationship between them. The description adds no semantic value beyond the schema's raw property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Trigger materialization and poll until complete or timeout.' It uses a specific verb (trigger) and resource (materialization), and it adds the polling behavior, which distinguishes it from a simple trigger. However, it doesn't explicitly contrast with sibling tools like sigma_materialize_element or sigma_get_materialization_job, so it misses a point for explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 you need both to trigger materialization and wait for completion. However, it provides no explicit exclusions or alternatives, such as 'instead of calling sigma_materialize_element and sigma_get_materialization_job separately.' The guidance is thus 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint=false (write operation) and idempotentHint=true, the description adds no additional behavioral context. It does not disclose whether the operation overwrites existing values, adds to existing assignments, requires specific permissions, or how it handles non-existent teams or attributes. The example is more about parameter structure than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence stating the purpose, followed by a parameter definition and example. It is front-loaded with the core action and includes a concrete example that clarifies the structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are covered. The description is adequate for a simple set operation but incomplete: it does not document attribute_id, does not explain the difference from update tools, and lacks behavioral details like idempotency/overwrite semantics. The example helps but leaves gaps for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 provide a clear structure and example for the 'assignments' parameter, which is otherwise just an array of objects with additionalProperties. However, it completely omits any explanation of 'attribute_id', leaving that parameter to be inferred from its name. The compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a user attribute value for specific teams.' This identifies the verb (set), the resource (user attribute value), and the scope (specific teams). It distinguishes from tools like sigma_set_user_attribute_for_tenants but does not clarify the difference with sigma_update_user_attribute_for_teams, which could be a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, exclusions, or relationship to update/delete/get user attribute team tools. The only extra information is an example for the assignments parameter, which is about parameter format, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the annotations. It does not mention side effects, idempotency implications, or any effect on existing grants, even though the annotations already convey that it is a non-destructive, idempotent write operation. The bar is lower with annotations, but the description adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It opens with the main purpose, then provides a clean bullet list of the key parameter values. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter mutation tool with an output schema, the description gives the essential purpose and parameter values. However, it lacks any context about when to use this vs. other grant tools, how it interacts with existing grants, or any prerequisites. It is minimally viable but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clearly defines grant_type ('member' or 'team') and permission ('annotate' vs. 'usage') with human-readable meanings. Though connection_id and grantee_id are not defined, their roles are implied by context and grant_type. This is a solid compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a grant to a connection' with a specific verb and resource. It is distinct from sibling grant tools like sigma_grant_workbook_access and sigma_grant_workspace_access, though it does not explicitly name alternatives. The additional lines about grant_type and permission further clarify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_create_grant, sigma_list_connection_grants, or sigma_delete_connection_path_grant. The description implies its purpose but does not specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context beyond the one-line statement, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though arguably too minimal, but it earns its place by stating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with an output schema and annotations, the description is minimally sufficient. However, it lacks explicit connection to the policy_id parameter and does not differentiate from the list sibling, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, policy_id, with title 'Policy Id' and type string, which is self-explanatory. The description adds no param information, and with 0% schema coverage it should compensate, but the single simple parameter mitigates the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a source swap policy' clearly states the verb 'get' and the resource 'source swap policy', indicating a single-policy retrieval. It distinguishes from the sibling 'list_source_swap_policies' via singular vs. plural, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites like obtaining the policy_id from a list operation, or any context for when a source swap policy would be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. It does not explain what 'lineage' entails (e.g., upstream/downstream dependencies, depth, pagination) or any side effects. The annotations (readOnlyHint=true, destructiveHint=false) cover read-only safety, but the description itself discloses no additional traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter), read-only annotations, and existing output schema, the description is minimally adequate. However, it lacks any explanation of what 'lineage' includes or how it differs from other report-related list tools, so it is not fully complete for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (report_id) with zero description coverage. The tool description does not explicitly explain report_id, its format, or how to obtain it. The phrase 'for a report' implies the ID references a report, but this is not enough 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List lineage for a report.' It uses a specific verb ('list') and a specific resource ('lineage for a report'), and it distinguishes itself from sibling tools like sigma_list_workbook_lineage and sigma_list_data_model_lineage by focusing on reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_list_report_sources or sigma_list_workbook_lineage. There is no mention of prerequisites, exclusions, or situational recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds only the scope 'in the organization', which is useful context, but it does not disclose pagination behavior or the effect of the limit parameter. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and scope with no unnecessary words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the output schema, and annotations, the description is minimally viable. However, it omits any mention of the limit parameter and does not clarify how this tool differs from listing shared templates. These omissions could lead to incorrect usage, so a bit more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'limit', with 0% description coverage. The tool description does not mention this parameter at all, leaving its purpose and behavior entirely undocumented in both the schema and the description. The description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with the resource 'templates' and clarifies scope as 'in the organization', making the tool's purpose unambiguous. It also implicitly distinguishes from the sibling tool sigma_list_shared_templates by emphasizing org ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like sigma_get_template or sigma_list_shared_templates. The description simply states what it does without any contextual or exclusions; the agent is left to infer when it is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries little burden for safety disclosure. However, it adds no extra behavioral context such as whether lineage includes upstream/downstream dependencies, pagination behavior, or scoping. The description essentially restates the tool name without revealing any additional traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and immediately informs the agent of the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema, which reduces the need for detailed return-value explanations. However, the description lacks usage guidance and parameter clarification, making it minimally viable but with clear gaps. It is not as complete as a well-rounded description would be for a similar list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 workbook_id parameter. While the parameter name is somewhat self-explanatory, the description does not compensate for the lack of schema documentation by providing details about expected format, requirements, or how it affects the lineage listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List data lineage for a workbook' uses a specific verb (list) and resource (data lineage for a workbook), clearly distinguishing it from sibling tools that list lineage for data models or reports. It is precise and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no examples, exclusions, or references to other tools like sigma_list_data_model_lineage or sigma_list_report_lineage. The description only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a mutating operation that is not destructive. The description adds no further context: it does not state whether this appends to existing documents, replaces them, or has any side effects. With no schema descriptions, the agent is left guessing about actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and target, making it easy to parse. Perfectly concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation with two parameters and no parameter documentation. The description does not address what happens to existing deployment documents, whether duplicates are allowed, or any prerequisites. Although an output schema exists (not shown here), the missing behavioral context and parameter guidance leave the tool under-specified for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameters. It uses the term 'workbooks/reports' which vaguely hints at inode_ids, but it never explicitly maps that to the parameter. policy_id is left completely undefined. The description adds minimal semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and clearly identifies the resource ('workbooks/reports') and destination ('deployment policy'). It distinguishes from sibling tools like sigma_create_deployment (which creates the policy) and sigma_list_deployment_documents (which lists documents), so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb and resource: you use this tool when you need to attach workbooks/reports to an existing deployment policy. However, there is no explicit mention of when not to use it or alternatives, e.g., whether you need a created policy first or if there is a bulk operation for this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds no further behavioral context such as error scenarios, permission requirements, or response format. It essentially restates the tool's purpose without disclosing additional traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, containing no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one self-explanatory required parameter, an output schema, and strong annotations. The description sufficiently states the purpose for a basic getter, though it lacks usage guidance; overall it is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains only attribute_id with no description, and the description does not elaborate on this parameter. While the name is somewhat self-explanatory, with zero schema coverage the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('all team assignments for a user attribute'), clearly distinguishing it from sibling tools like sigma_set_user_attribute_for_teams and sigma_get_user_attribute_users. It unambiguously states 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.
Usage Guidelines2/5
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_get_user_attribute_users or sigma_set_user_attribute_for_teams. It only states the function without any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false, destructiveHint=false), but the description adds no extra behavioral context beyond the word 'swap'. It does not disclose side effects, permissions, reversibility, or impact on dependent entities, which would be valuable for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. Every word contributes to understanding the tool's purpose and parameter usage, making it very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and parameter roles, but lacks details about the structure of the mapping objects, whether both mappings can be used together, or any edge cases. With an output schema present, return values are covered, but the operational context is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of the two mapping parameters ('connection-level swaps' vs 'table-level swaps'), which adds meaning beyond the schema's bare types. However, the naming in the description (camelCase) does not match the schema property names (snake_case), and the required template_id is not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Swap' and the resource 'data sources on a template', which distinguishes it from sibling tools for other resource types (workbooks, data models, reports). The specificity is high and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on choosing between connectionMapping and sourceMapping, but does not indicate when to use this tool versus alternative swap tools for other resources. No prerequisites, exclusions, or scenarios are mentioned, so it lacks clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 a list of example properties but does not disclose side effects (e.g., setting isActive to false is effectively a deactivation), partial-update semantics, or authentication requirements. It does not contradict annotations, and the 'etc.' aligns with openWorldHint true, but the added context is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and provides concrete examples. It contains no filler or redundant information, earning a maximum score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the schema (2 params, open body) and the presence of an output schema, the description is moderately complete. However, it lacks clarity on update semantics (e.g., whether all fields are optional, how isActive interacts with sigma_deactivate_member) and does not reference sibling tools for specific use cases. The description is sufficient for a basic understanding but leaves gaps for an agent to correctly construct the body object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It names some body properties (firstName, lastName, memberType, isActive) but leaves 'etc.' ambiguous. It does not explain whether body is a partial update or full replacement, nor does it describe member_id beyond what the name implies. The open-world nature of body is hinted but not fully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates member properties and lists specific fields (firstName, lastName, memberType, isActive). It is a specific verb+resource combination, but does not explicitly differentiate from sibling tools like sigma_deactivate_member or sigma_change_member_email, which also modify member data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools such as sigma_deactivate_member, sigma_change_member_email, and sigma_update_team_members exist, but the description does not clarify that this tool is for general profile updates, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false and destructive=false, so the write/non-destructive nature is known. The description adds context about 'scheduled export' and points to docs for the body schema, but does not disclose side effects, permissions, or response behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action, and the second clause points to documentation. It has no wasted words, though the external doc reference is a slight evasion of inline explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a free-form nested body, open-world hint, and no parameter documentation in the schema. The description defers all body schema details to external docs, making it incomplete for an agent to invoke correctly without additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 workbook_id or the body structure beyond saying 'See Sigma docs for schedule body schema.' Given the body has additionalProperties=true, the agent gets no meaningful parameter semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('scheduled export for a workbook'), clearly distinguishing it from sibling tools that list, delete, or create report schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies use for creating a workbook schedule, but it does not explicitly state when to use this over alternatives like list_workbook_schedules or create_report_schedule, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context (e.g., error handling, permissions, or response format), but neither does it contradict the annotations. Given the annotations, the minimal description is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. Every part ('Get', 'details', 'API connector') contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a simple read-only operation, the description is minimally sufficient. However, it omits any guidance on when this tool should be selected over similar 'get' tools, and does not mention that it retrieves a specific connector by ID, which is already obvious from the parameter. For a tool with a rich sibling set, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not elaborate on 'connector_id' beyond the parameter name. It does not explain how to obtain it, its format, or its purpose, leaving the agent to infer from the name alone. For a single self-explanatory parameter, the lack of added semantics is a minor but real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details for an API connector' uses a specific verb ('get') and resource ('API connector'), clearly distinguishing it from sibling tools like 'sigma_list_api_connectors' which lists connectors. It accurately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'sigma_list_api_connectors' or 'sigma_get_connection'. The description does not state any prerequisites, exclusions, or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no extra behavioral context beyond the name, but it is consistent with the annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is perfectly front-loaded. Every word earns its place with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an output schema, the description is minimally adequate. However, it does not clarify what the version history includes or how it relates to restore_workbook_version, so it feels somewhat incomplete for an agent deciding between related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 workbook_id parameter. The parameter name is self-explanatory, but the description provides no additional meaning or format details, which is a gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get version history for a workbook.' It clearly distinguishes from siblings like sigma_get_workbook (which gets workbook details) and sigma_restore_workbook_version (which restores a specific version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_restore_workbook_version or sigma_get_workbook. The description simply states what it does without providing context on when to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context (e.g., pagination, permissions, or limitations) beyond what annotations provide, but it does not contradict them either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It conveys the core purpose efficiently and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter structure, output schema presence, and read-only annotations, the description is adequate but somewhat bare. It lacks context about what 'SQL queries' means in this context or how to obtain a report_id, and does not reference related tools. The combination of annotations and schema covers the core, but the description adds minimal extra value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only says 'in a report' which gives minimal context for the report_id parameter. It does not explain report_id's format, expected values, or how it relates to the returned queries, leaving the agent to infer from the parameter name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List SQL queries in a report' clearly states the action (list) and the resource (SQL queries in a report), which is specific and distinguishes it from sibling tools like sigma_list_workbook_queries. It unambiguously identifies the scope as report-level rather than workbook-level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, nor any exclusions, prerequisites, or context about typical use cases. The description is a bare statement with no mention of alternatives, making it hard for an agent to know when to select this over similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds no extra behavioral context. It does not disclose whether results are complete, paginated, or what happens if the team does not exist. For a list operation, this is a minimal but acceptable gap, yet the description adds no value beyond what the annotations already declare.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of five words: 'List members of a team.' It is extremely concise and contains no redundant or filler content, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, and an output schema that presumably documents return structure), the description is nearly complete. It does not mention return values or pagination, but the output schema likely covers that. The only minor gap is not noting the team_id requirement explicitly, though that is implied by the resource phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter (team_id). The description's phrase 'of a team' implies that team_id identifies the team whose members are listed, adding some meaning beyond the bare schema field name. However, it does not explain the format, required permissions, or relationship to other team entities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List members of a team' uses a specific verb ('List') and a clear resource ('members of a team'), which directly distinguishes it from sibling tools like sigma_list_members (which lists all members) and sigma_list_member_teams (which lists teams for a member). The team scoping is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_members, sigma_get_member, or sigma_update_team_members. The description offers no contextual cues about prerequisites, team ID requirements, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no behavioral context beyond stating the purpose, such as performance implications, output structure, or any caveats about which elements have queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence (eight words) that is front-loaded and contains no unnecessary information. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, read-only, output schema present), the description is mostly complete. It states the scope clearly, but lacks usage guidance and any notes on limitations, which keeps it from being fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (workbook_id) with no description (0% coverage). The description references 'in a workbook' to indicate the parameter's role, but does not provide any additional detail about expected values or format. This is minimal compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('generated SQL queries for all elements in a workbook'), providing a specific verb and scope. This distinguishes it from single-element query tools like sigma_get_element_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_get_element_query or sigma_list_report_queries. The description implies usage through its functionality but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnly=false) and non-destructive (destructive=false). The description adds destination context but does not disclose potential side effects, permission requirements, or name conflict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, then parameter clarification. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core action and destination are clear, the description omits edge-case behaviors like overwriting existing files, permission requirements, or whether a folder must exist. Output schema exists but is not shown; still, a copy operation may need more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The description explains the 'name' parameter's default behavior. It implicitly clarifies workbook_id and member_id through its phrasing, but doesn't provide explicit details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States explicit verb 'Copy' with specific resource 'workbook' and destination 'member's My Documents folder'. Clearly distinguishes from sibling tools like sigma_duplicate_workbook or sigma_create_workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_duplicate_workbook or sigma_deploy_template_to_folder. It does not specify prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond annotations. It does not mention side effects such as sending invitations, permission requirements, or whether the member is immediately active. The only added information is the list of member_type values, which is more parameter semantics than behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action, and includes essential parameter clarification. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema and annotations cover return values and safety, the description lacks important context for a create operation, such as whether an invite email is sent, admin permissions are required, or what happens on duplicate emails. This makes it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines the allowed values for the 'member_type' parameter ('admin', 'creator', 'viewer'), which is critical since the schema has no enum or description. The other parameters (email, first_name, last_name) are self-explanatory, so no additional explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new member') with a specific resource. This distinguishes it from sibling tools like 'get_member' and 'update_member', which are different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, exclusions, or related tools like 'sigma_onboard_member' or 'sigma_bulk_assign_team_members', leaving the agent with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. However, the description adds no additional behavioral context such as pagination, ordering, or required permissions, which would be more valuable given the sparse information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence conveying the essential action and resource without any fluff. It is appropriately sized and front-loaded, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with an output schema, the description covers the core purpose. Minor gaps include not explaining what a 'tenant assignment' is or how attribute_id is used, but these are largely recoverable from the tool name and parameter name, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (attribute_id) with 0% description coverage. The description does not mention the parameter or how it relates to the tool's purpose, forcing the agent to rely entirely on the parameter name for meaning. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource ('all tenant assignments for a user attribute'), which distinguishes it from sibling tools that set or update user attribute assignments. The scope ('all') is also clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit when-to-use or alternative guidance. It implies usage for retrieving tenant assignments but does not name any alternative tools or exclusions, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond the action itself, such as pagination, permissions, or lineage scope, but there is no contradiction and the tool is a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the action and object. There is no wasted wording or unnecessary detail, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list operation with an output schema and safe annotations, the description is mostly complete. It lacks lineage-specific context (e.g., does it show upstream/downstream? is there depth?), but given the simplicity and available structured data, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. While 'for a data model' implies the data_model_id refers to a data model, it does not explain the parameter format, required structure, or any additional semantics beyond what the name 'Data Model Id' already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('lineage for a data model'). It distinguishes from sibling tools like sigma_list_workbook_lineage and sigma_list_report_lineage by explicitly naming the data model resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention when to choose sigma_list_data_model_lineage over sigma_list_workbook_lineage or sigma_list_report_lineage, nor does it describe any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is established. The description adds the filter behavior and allowed type values, but does not disclose additional behavioral traits like pagination, scope (e.g., only immediate children), or result structure. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. Every word contributes: it states the resource, action, and optional filter criteria. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional filters, read-only) and the presence of an output schema, the description is sufficient. It covers the essential filtering options. It could mention whether the list is recursive or only immediate children, but that is likely inferable from context or the output schema. Overall, it's complete for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: parentId (mapped to parent_id) and type (mapped to type_filter), including the allowed type values. It doesn't elaborate on what parentId refers to (e.g., folder ID), but the mapping is understandable and the type enum is explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists files/folders and mentions optional filters, using a specific verb and resource. It does not explicitly differentiate from sibling tools like sigma_list_all_files, which likely has a broader scope, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_list_all_files or sigma_list_workbooks. It lacks any exclusions or context for choosing this tool, such as whether it lists only top-level items or all descendants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context beyond the annotation, only scoping the result to a specific report without detailing output structure or any filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, condensed sentence with no unnecessary words, achieving maximum clarity in minimum length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list operation, the description covers the essential action and scope. The presence of an output schema and clear annotations lowers the burden, though usage guidance and parameter semantics are minimally addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on the report_id parameter. While the parameter name is self-explanatory, the description does not add format or usage details, failing to compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'data sources used by a report', clearly distinguishing from sibling tools like sigma_list_workbook_sources. It is unambiguous and immediately scopes the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_workbook_sources or sigma_list_report_queries. The description simply states the action without context on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds page scoping, but no additional behavioral details such as pagination, ordering, or what counts as an 'element'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states exactly what the tool does in the most efficient way possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two self-explanatory parameters, an output schema, and read-safe annotations, the description is largely sufficient. A small gap remains in not referencing related tools or response shape, but overall it is complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to bear the burden. It mentions 'specific page', which clarifies page_id, but does not explain workbook_id or the expected format/value semantics beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List elements on a specific page of a workbook' uses a specific verb ('List'), names the resource ('elements'), and includes a clear scope ('specific page'), distinguishing it from sibling tools like sigma_list_workbook_elements and sigma_list_workbook_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_workbook_elements, sigma_list_workbook_pages, or sigma_get_element_query. The context is implied by the name but not explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, open-world operation. The description adds the sequence 'create account then add to teams,' which is useful behavioral context. However, it does not disclose what happens if team assignment fails, whether the account creation is rolled back, or if there are side effects beyond these steps — with openWorldHint true, that would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('Onboard a new member') and efficiently explains the workflow. There is no redundancy; every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a multi-step operation with 5 parameters and no parameter descriptions, this tool needs more context. The description omits valid member_type values, precondition that the member must not already exist, and failure handling for partial completion. The output schema is present, somewhat reducing the need to describe returns, but the operation-level gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. Parameter names are somewhat self-explanatory, but 'member_type' is unexplained (what values are valid?), and 'team_ids' is not explicitly linked to the 'add to teams' step. The default 'viewer' for member_type and null for team_ids lack context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'onboard a new member' and clarifies it as a composite workflow: 'create account then add to teams.' This distinguishes it from sibling tools like sigma_create_member (which only creates an account) and sigma_bulk_assign_team_members (which only assigns teams).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for onboarding new members who need both an account and team membership, but it does not explicitly state when to prefer this over separately calling create_member and update_team_members, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context, such as whether existing values are overwritten, how unknown tenants are handled, or any side effects. It neither contradicts nor enriches the annotation profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and an example. The core action is front-loaded, and every part contributes useful information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the core action and assignment structure, and an output schema exists to explain return values. However, it lacks any differentiation from closely related sibling tools (e.g., sigma_set_user_attribute_for_teams, sigma_update_user_attribute_for_tenants, sigma_delete_user_attribute_for_tenant), which is a notable gap given the large tool family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage and leaves the 'assignments' object structure open (additionalProperties: true). The description compensates by specifying each object has 'tenantOrganizationId' (str) and 'value' (str) and provides a concrete example, adding meaningful structure beyond the bare schema. However, it does not elaborate on 'attribute_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('a user attribute value'), and the scope ('for specific tenants'). This distinguishes it from the sibling tool sigma_set_user_attribute_for_teams, which operates on teams instead of tenants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_set_user_attribute_for_teams or sigma_update_user_attribute_for_tenants. The description only states the action and parameter format, leaving usage context to be inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate that. The description adds the confirm=True requirement, which is a meaningful safety check beyond the annotations. However, it does not disclose whether the deletion is reversible, what happens to associated data, or if certain permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that conveys the core action and a critical requirement. No filler words; every element earns its place. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and annotations that indicate destructive behavior, the description covers the essential aspects: what it does and the confirmation requirement. It lacks details on reversibility or prerequisites, but for a simple delete operation, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explicitly explains the confirm parameter, noting it must be true to execute the deletion. However, policy_id is not described beyond its name, which is fairly self-explanatory but still a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resource ('a deployment policy'), with 'archive' providing additional context that it may be a soft delete. This distinguishes it from sibling tools like sigma_create_deployment or sigma_get_deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the requirement 'Requires confirm=True', which is a precondition rather than guidance on when to use this tool versus alternatives. It does not mention when one should delete or archive a deployment policy, nor does it reference alternative tools like sigma_delete_workspace or sigma_list_deployments for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the operation is batched ('in one call') but does not disclose other behavioral traits such as handling of duplicate memberships or atomicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, clearly stating the action and scope. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and presence of an output schema, the description is largely complete. It covers the batch aspect ('in one call') but could benefit from mentioning error scenarios or idempotency. Still, it is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description minimally compensates by using 'members' and 'team' to imply team_id and member_ids. However, it adds no deeper semantics beyond the schema's names and types, such as ID formats or edge-case behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add', a clear resource ('multiple members to a team'), and a scope ('in one call'). This effectively distinguishes it from siblings like sigma_list_team_members (read) and sigma_update_team_members (update vs. add).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives, nor does it mention prerequisites or scenarios (e.g., bulk add vs. incremental updates). Sibling tools are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the footnote 'DESTRUCTIVE.' and 'Requires confirm=True.' The destructive nature is already declared by destructiveHint=true, but the requirement for a confirm flag is an extra behavioral detail not present in the annotations. This helps the agent understand the tool's safety guardrail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences: the action, the destructiveness flag, and the confirmation requirement. Every sentence contributes a distinct piece of information, and there is no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation, the description covers the core action and the confirm requirement. However, it lacks context on when to use this tool versus related grant tools, what the consequences of deletion are (e.g., revoking access), and prerequisites. It is adequate but minimal, relying on the schema and annotations for additional structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'confirm=True' in prose. The parameters workspace_id and grant_id are not described beyond their self-explanatory names; there is no guidance on their formats, where to find them, or how they relate to the operation. This is a significant gap given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a permission grant from a workspace.' It uses a specific verb ('Delete') and identifies the resource ('permission grant from a workspace'), which distinguishes it from sibling deletion tools like sigma_delete_workspace and sigma_delete_connection_path_grant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of use cases, prerequisites, or situations where a different tool (e.g., sigma_delete_connection_path_grant) should be used. The only instruction is 'Requires confirm=True,' which is a safety requirement rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the two-step process (instantiate then optionally swap sources) beyond the annotations, which already indicate the operation is not read-only or destructive. However, it does not disclose what artifacts are created, whether the operation is transactional, or what 'sources' refers to concretely, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key concept ('Full deployment') and then expands with a concrete explanation. Every word adds value, with no redundant fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too brief for a tool with 4 parameters, 3 required, and zero schema descriptions. It fails to explain the 'name' parameter, the semantics of connection_mapping, prerequisites, or expected outcomes. The combination of instantiation and source swapping is complex and needs more elaboration to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides some meaning by linking template_id to 'template' and folder_id to 'folder', and 'swapping its sources' likely relates to connection_mapping. However, the required 'name' parameter is unexplained, as is the structure of connection_mapping, so partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('instantiate') and resource ('template into a folder'), and distinguishes it from simple alternatives like create_workbook_from_template or swap_template_sources by describing it as a 'full deployment' that optionally swaps sources. This is precise and differentiates the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the 'full deployment' option but does not explicitly state when to use this tool versus alternatives such as sigma_create_workbook_from_template or sigma_swap_template_sources. No exclusions or alternative guidance is provided, so the agent must infer context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only behavior (readOnlyHint=false). The description adds that this is a cloning operation and clarifies that name and destination_folder_id are required by the API, which provides marginal context. However, it does not disclose side effects (e.g., whether the original report is unchanged), permissions needed, or any other behavioral nuances, leaving some ambiguity for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action, followed by a parameter list. The parameter list is useful given the schema's lack of descriptions, but the repeated 'required by the API' phrase is redundant because the schema already marks all three as required. Slightly trimmed, it would be ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple duplication tool, the description covers the core action and all parameters. The presence of an output schema means return values are documented elsewhere. However, it lacks any usage context, relationship to sibling tools, or notes on behavior like whether the source is preserved. This makes it minimally complete but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter's role: report_id is the source report to clone, name is the new report's name, and destination_folder_id is the target folder. This adds meaning beyond the bare parameter titles and clarifies the source/destination relationships, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 a report.' This clearly distinguishes it from sibling tools like sigma_create_report (creating a new report) and sigma_duplicate_workbook (duplicating a different resource). 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as sigma_create_report or sigma_duplicate_workbook. It simply states the operation without any contextual conditions or exclusions. There is no mention of prerequisites, use cases, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds useful behavioral details: empty element_id exports the first page, and layout only applies to pdf/png. It does not disclose potential side effects, asynchronous behavior, or permissions, so transparency remains moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the main action followed by brief parameter-level notes. Every line adds value with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core export behavior, formats, and fallback logic, and the output schema helps with return value expectations. However, it does not address async execution, file delivery mechanisms, or relationship to sibling export tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates well by listing allowed values for format, layout, and explaining element_id fallback behavior. workbook_id is not described but is self-evident from the tool name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export a workbook element') and specifies the resource and scope. It does not explicitly differentiate from the sibling sigma_export_report, but the workbook context and element/fallback behavior make the purpose reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on element_id omission and format/layout constraints, which implies usage context. However, it does not explicitly state when to choose this tool over alternatives like sigma_export_report or sigma_export_and_download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds valuable context about the underlying mechanism (RFC 8693 token exchange) and the specific endpoint called (/whoami). This goes beyond the annotation hints by explaining how the operation is performed and what 'scoped identity' means, which helps the agent anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using two short sentences to convey the purpose and mechanism. It is front-loaded with the main action ('Demonstrate tenant token exchange') and wastes no words. Every sentence is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, and an output schema available), the description provides sufficient context about what the tool does and the steps involved. It does not describe return values, but that is covered by the output schema. The only weakness is the lack of explicit param mapping and usage exclusions, which are already captured in other dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate by explaining the tenant_org_id parameter, but it does not. The description mentions 'tenant-scoped' without explicitly linking it to the parameter or describing what the tenant_org_id represents, its format, or its role in the token exchange. The parameter remains under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: demonstrating tenant token exchange by calling /whoami through a tenant-scoped client. This distinguishes it from sigma_get_current_user (which likely uses the existing user context) by emphasizing the tenant-scoped token exchange. The word 'Demonstrate' introduces slight ambiguity about whether this is a utility or an example, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to verify a tenant-scoped identity after token exchange, but it does not provide explicit guidance on when to use it versus alternatives like sigma_get_current_user or sigma_get_tenant. No when-not or alternative tools are mentioned, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the read-only annotations (readOnlyHint=true, destructiveHint=false) and does not contradict them. However, it adds no extra behavioral context such as pagination, ordering, or authorization needs, relying entirely on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and communicates the essential action immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, read-only annotations, and an output schema, the description is adequate for understanding the core function. However, it does not clarify how this differs from sigma_list_tags (global tag listing), which could be relevant for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter. The description implies that workbook_id identifies the workbook whose tags are listed, which provides some meaning, but it does not explain the ID format or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'tags on a workbook', precisely indicating the operation. It distinguishes from sibling tools like sigma_list_tags by scoping tags to a specific workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like sigma_list_tags or sigma_tag_workbook. No comparison, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description only restates the basic behavior and does not add context about large result sets, pagination, or any other behavioral traits. It is consistent with annotations but adds no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the action and scope without extraneous details. It is front-loaded with the verb and object, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one required parameter, and an output schema exists. However, the description does not mention the required parameter or any limitations, relying on the schema and tool name to provide that information. For a simple read-only list operation, this is marginally adequate but could be improved by mentioning the data_model_id dependency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, data_model_id, with no description. The tool description does not mention the parameter at all, so it provides no compensation for the 0% schema coverage. The agent must infer the parameter from the name and schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly specifies the resource: 'all columns across all elements in a data model.' This distinguishes it from sibling tools like sigma_list_columns_for_table, which targets a table, and sigma_list_workbook_columns, which targets a workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the function but does not mention when to use it over alternatives, nor provide any exclusions or references to sibling tools. The use case is implied by the wording, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context, only specifying the resource type; it does not disclose details like pagination or grant types, but the output schema fills some gaps. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in one clear sentence. The second sentence 'Required: inodeId' is redundant with the schema but adds emphasis without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with output schema and annotations, the description covers the essential purpose and required parameter. It lacks comparison with sibling grant-listing tools, but the invocation requirements are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions 'inodeId' and indicates it is required, tying it to the resource type, but does not explain its format, how to obtain it, or constraints beyond being required. This is partial but insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'List' and the resource 'grants for a specific file/workbook/data model by inodeId', making the tool's purpose clear and distinguishable from other grant-related tools. It does not explicitly compare with siblings like sigma_list_workbook_grants, so it stops 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need grants for a file/workbook/data model and have its inodeId. It lacks explicit exclusions or alternative tool references, but the context is unambiguous and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context, only clarifying that schedules pertain to exports, but does not mention pagination, filtering, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words, front-loaded with the action. Perfectly concise for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with an output schema available, the description is complete. It could mention the existence of add/delete schedule tools, but that is not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It relates the workbook_id parameter to the action ('for a workbook'), but does not explain the format or constraints beyond the parameter name. The parameter name is self-explanatory, so the addition is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists scheduled exports for a specific workbook. The verb 'list' and resource 'scheduled exports for a workbook' are specific and distinguish it from sibling tools like sigma_list_workbooks or sigma_list_workbook_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sigma_list_report_schedules or sigma_list_materialization_schedules. The intended use is implied but not differentiated from related schedule-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=false and destructiveHint=false, so the description's addition of 'become visible in Sigma' provides some behavioral context. However, it does not mention potential side effects such as long-running operation, whether it alters existing metadata, or if it is asynchronous. Minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. Every word adds value, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations provide basic safety hints, the description is minimally complete. However, for a bulk operation like syncing all tables, it could benefit from explaining whether it is one-time or recurring, potential performance implications, or prerequisites. It does not describe the return value or error behavior, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden for parameter understanding. It only implies that database and schema refer to the warehouse location, and connection_id is the connection, but it does not explain each parameter individually or provide any detail about value formats. This is insufficient for a 3-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: syncing all tables in a warehouse schema to make them visible in Sigma. The verb 'sync' and resource 'all tables in a warehouse schema' are specific, and this distinguishes it from siblings like sigma_sync_connection which handles connection-level syncing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to make tables visible in Sigma) but does not explicitly mention alternatives or scenarios like after adding new tables vs. initial setup. There are no exclusions or guidance on when not to use it, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, and open-world behavior. The description adds valuable behavioral context: it lists tenants, exchanges tokens, syncs each connection, uses bounded concurrency, and returns an error if token exchange fails. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by a clear algorithm and requirements. The 'Phase C' note adds minor noise, but every other sentence earns its place, making it appropriately concise without sacrificing necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the high-level process, auth requirements, and error behavior well. However, it omits the semantics of the only parameter (dry_run), which is critical for a bulk operation with side effects. The output schema exists, so return values are covered, but the missing parameter documentation prevents full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, dry_run, has a default of true and no schema description (0% coverage). The description never mentions dry_run or its effect, leaving the agent without crucial information about whether the tool will actually mutate state or just preview changes. This is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sync' and the resource 'connections across all tenant organizations', distinguishing it from single-tenant sync tools like sigma_sync_connection. It also outlines the multi-step process invoked, leaving no doubt about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a bulk operation across all tenants and mentions prerequisites (multi-tenant auth, PyJWT). It does not explicitly name alternatives or when-not-to-use, but the bulk vs. single scope is implicit in the name and sibling list, so this is more than adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the create-or-update dual behavior, but does not disclose side effects, permission requirements, or update semantics. Minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, no redundancy. Action and required inputs are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core inputs but misses usage context relative to sibling grant management tools. With an output schema available, return values are covered. Lacks guidance on when to use this generic grant creator versus specialized alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a generic 'body' object with additionalProperties. The description specifies the four required fields (inodeId, granteeId, permission, type), significantly compensating for schema gaps. However, it doesn't explain valid values for permission or type, limiting full parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates or updates a grant, using specific verbs and a resource type. The required body fields are listed, distinguishing it from other grant-related tools like sigma_grant_workbook_access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling grant tools (workbook access, workspace access, connection grants). The description only describes the action, not selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safe write nature is known. The description adds context about the API requirement for color and a default, but does not disclose behaviors beyond annotations, such as behavior on duplicate tag names or whether creation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action. The parameter details are inline but could benefit from a more structured layout. Every sentence contributes value with no fluff, though the formatting is slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with an output schema and clear annotations, the description is mostly complete. It explains the purpose, one key parameter, and a default. It does not cover potential duplicate handling or mention related tags, but overall it is sufficient for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining the 'color' parameter with allowed values and default. However, the 'name' parameter is not explicitly described; while implied by 'Create a new tag', its format or constraints are not stated, leaving room for confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new tag' with a specific verb and resource, and adds a use case ('used for version promotion like Production, Staging') that distinguishes it from sibling tools like sigma_list_tags and sigma_delete_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an implied use case (version promotion) but does not explicitly mention when to use this tool versus alternatives such as sigma_list_tags for finding existing tags or sigma_tag_workbook for applying a tag. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 no behavioral context beyond that, such as idempotency, overwrite behavior, permissions required, or what happens on duplicate names. It merely repeats the 'create' action without disclosing side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single purpose statement followed by a structured parameter list. Every sentence earns its place, with no filler or repetition. The bullet-style parameter documentation is easily scannable and avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation with three well-documented parameters and an output schema present, so return values need not be explained. However, it lacks context about the relationship to other user attribute tools (e.g., that created attributes are later assigned to teams/tenants) and does not mention any prerequisites or post-conditions. This makes it minimally viable but leaves some contextual gaps for an agent unfamiliar with Sigma's user attribute model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema_description_coverage is 0%, the description provides explicit explanations and examples for all three parameters: name ('e.g. Region, CustomerID'), default_value ('Default string value assigned when no override exists'), and description ('Optional description'). This adds meaning beyond the bare schema, which only lists titles and defaults. However, it does not delve into edge cases or type constraints, so it's not a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a user attribute for RLS or dynamic parameters.' This specific verb+resource combination distinguishes it from sibling tools like sigma_set_user_attribute_for_teams, which assign values to teams, and sigma_list_user_attributes, which lists existing attributes. 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating user attributes as opposed to setting them for specific teams or tenants, but it does not explicitly state when to use this versus alternatives. It provides no 'when to use' or 'when not to use' guidance, and the mention of 'RLS or dynamic parameters' hints at use cases but lacks direct exclusions. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds that the result includes real charts/tables, which is useful functional context. However, it does not disclose operational details like permission requirements, default naming behavior, or what happens on failure, leaving the description to carry only moderate additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. The first sentence states the primary action, and the second adds a key differentiator (visuals). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and simple parameters, the description is mostly complete for selecting and invoking the tool. It explains the unique value proposition and leaves parameter details to the schema. It lacks explicit guidance on how to obtain template_id/folder_id, but sibling tools exist for that, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the three parameters (template_id, folder_id, name). It only says 'from a template,' which does not add meaning beyond the schema's property names. The description completely fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create a workbook from a template') and explicitly differentiates from alternatives by noting it is the only programmatic way to get charts/tables. This clearly distinguishes it from sibling tools like sigma_create_workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when you need a workbook with real visuals), and implicitly contrasts it with other creation methods. It does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the 'List' verb. Annotations already declare readOnlyHint=true and destructiveHint=false, but the description does not disclose any additional traits such as output format, filtering limitations, or access requirements. It is entirely redundant with the tool name and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It front-loads the verb and quickly communicates the resource and scope, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and annotations that cover safety, a brief description may suffice. However, the description lacks any usage guidance or differentiation from similar column-listing tools, making it minimally complete but not richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'specific element' and 'workbook' map naturally to the required element_id and workbook_id parameters. However, it provides no elaboration on parameter constraints or relationships beyond what the schema field names already convey. This partially compensates for the low coverage but does not fully explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('columns'), and the specific scope ('for a specific element in a workbook'). This distinguishes it from sibling tools like sigma_list_workbook_columns and sigma_list_columns_for_table, which operate at different granularity levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific element in a workbook' gives clear context that this tool is appropriate when an element_id and workbook_id are known and columns for that element are needed. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the detail that homeFolderId is included in the response, but it does not disclose additional behavioral aspects such as error conditions, pagination, or required permissions. With annotations present, the description provides some extra value but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key verb and resource. It contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and has an output schema, so the description does not need to explain return values. The description is sufficient to convey the basic operation, and the annotations cover safety. It is slightly limited in providing broader context, but given the tool's simplicity and the presence of structured metadata, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the single parameter member_id. The description does not explicitly explain the parameter, its purpose, or how to obtain it. The parameter name is self-explanatory, but the description provides no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (member details), with a specific detail (including homeFolderId). It differentiates from sibling tools like sigma_list_members by using 'get' for a single member versus 'list' for all members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to retrieve a specific member's details. However, it does not explicitly state when to use this tool over alternatives like sigma_list_members or sigma_get_current_user, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds the specific scope of 'user assignments' but does not provide additional behavioral context such as pagination, ordering, or edge cases. Since annotations cover the safety profile, the description adds moderate value but lacks rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without unnecessary words. It directly conveys the tool's purpose and earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an output schema, the description is largely complete. The annotations and output schema cover safety and return structure. However, the description could benefit from a brief note on what 'user assignments' entails or how 'all' is enumerated, but given the tool's simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 missing parameter documentation. It only says 'for a user attribute,' which vaguely maps to the 'attribute_id' parameter but does not explain the expected format, how to obtain the ID, or any constraints. This is insufficient to fully understand the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all user assignments for a user attribute.' It uses a specific verb ('Get') and identifies the resource ('user assignments') and the scope ('for a user attribute'). This distinguishes it from sibling tools like sigma_get_user_attribute_teams and sigma_get_user_attribute_tenants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage but does not explicitly state when to use this tool versus alternatives. It identifies the action (getting user assignments) but does not mention when not to use it or provide alternatives, such as using sigma_get_user_attribute_teams for team assignments. The context is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no extra behavioral context such as pagination, authorization requirements, or output format, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and object, with zero wasted words. It is perfectly efficient for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one parameter, an output schema, and safety annotations, the description is mostly complete. The only notable gap is the lack of detail on the member_id parameter format, but the overall simplicity and structured data mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 of explaining 'member_id.' It adds minimal context by indicating the member is the one whose teams are listed, but it does not specify the ID format or how to retrieve it, leaving the parameter under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'teams a member belongs to,' establishing a clear relationship. This distinguishes it from sibling tools like sigma_list_teams (all teams) and sigma_list_team_members (members of a team).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is clear: use this when you need to know which teams a specific member belongs to. However, the description provides no explicit guidance on when not to use it or alternatives, relying on the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context (e.g., pagination, response structure, required permissions). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It conveys the essential purpose clearly and succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema, the description is mostly complete. It falls slightly short by not clarifying whether the list includes controls from all pages or only top-level workbook controls, but given the simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, workbook_id, with no description (0% coverage). The tool description only says 'in a workbook', which adds minimal meaning beyond the parameter name and title. It does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list) and resource (control elements), and specifies the types (filters, parameters). This distinguishes it from sibling tools like sigma_list_workbook_elements that likely cover all element types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description, but there is no explicit guidance on when to choose this tool over alternatives such as sigma_list_workbook_elements or sigma_list_workbook_page_elements. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a behavioral hint about summary_only producing a 'concise token-efficient response', implying the full response could be verbose. However, it doesn't disclose return format or pagination behavior, which would add more value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality and a key usage tip. There is no wasted wording, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output schema and clear annotations, the description is largely sufficient. It covers the main purpose and gives a token-saving tip, which is useful context. However, it doesn't mention the limit parameter or distinguish from the very similar sigma_list_all_workbooks, leaving a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters. The description explains summary_only ('concise token-efficient response') but provides no meaning for the 'limit' parameter. With only one of two parameters explained, the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('workbooks') with clear scope ('in the organization'). This clearly distinguishes it from siblings like sigma_list_workbooks_shared_with_member, though it shares similarity with sigma_list_all_workbooks. 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('List all workbooks') and provides a practical tip for the summary_only parameter, but it doesn't explicitly state when to use this tool over alternatives like sigma_list_all_workbooks. No exclusions or alternative recommendations are given, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context (e.g., whether inherited grants are included, pagination, authorization needs), but it does not contradict the annotations. Minimal extra value is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundancy. It effectively communicates the tool's purpose in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple list tool has one obvious parameter, an output schema, and annotations covering safety. The description is sufficient for the tool's low complexity, though it could mention scope behaviors like 'all grants' or note any limitations. The output schema likely covers return structure, so no further detail is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 undocumented parameters. It does not explain workspace_id beyond its name, which is already evident from the schema. The single parameter is self-explanatory, but the description adds no semantic meaning or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('permission grants') and scope ('workspace'), making its purpose clear. It also distinguishes from sibling tools like sigma_list_workbook_grants and sigma_list_connection_grants by specifying 'workspace'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing workspace-level grants, but offers no explicit guidance on when to choose it over alternatives (e.g., sigma_list_grants or sigma_list_workbook_grants). No conditions, prerequisites, or exclusions are mentioned, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms this is a write operation (consistent with readOnlyHint=false) and instructs to provide member ID lists, but it does not disclose behaviors like whether the operation replaces the entire membership set, handles duplicates, or fails on invalid IDs. Annotations already cover read-only/safety, so the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb, no wasted words. Every sentence contributes meaning: the first states purpose, the second states the required input format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description leaves ambiguity about whether 'add or remove' means you can do both simultaneously, and it does not mention any caveats or output details. The presence of an output schema covers return values, but the description is not fully complete for a mutation tool with zero parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description partially compensates by clarifying that add and remove take lists of member IDs, which is the main semantic need. However, it does not explain the role of team_id or nuances like null defaults, so coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool adds or removes members from a team, with a specific verb and resource. It distinguishes from siblings like sigma_list_team_members (listing) and sigma_bulk_assign_team_members (bulk assignment) by focusing on adding/removing with explicit ID lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying team membership but does not explicitly mention when to use it over alternatives like sigma_bulk_assign_team_members or sigma_onboard_member. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and non-read-only behavior. The description adds the crucial 'Requires confirm=True' safeguard, which is not inferable from the schema alone, and provides an example for team_ids. It does not disclose reversibility or effects beyond revocation, but that is partially covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with two sentences plus a one-line parameter explanation and example. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and the confirm requirement, but omits the role of attribute_id and any relation to sibling tools. Given the tool's destructive nature and the presence of an output schema, the description could still be more complete, but it covers critical aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining team_ids as 'List of team IDs whose attribute assignments should be removed' and gives an example. However, it does not explain attribute_id or the semantics of confirm (beyond requiring true), leaving two of three parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Revoke a user attribute assignment for specific teams,' using a specific verb and resource. It distinguishes from siblings like sigma_set_user_attribute_for_teams by indicating revoke rather than set, but the name 'update' vs 'revoke' introduces slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires confirm=True') but no guidance on when to use this tool versus alternatives like sigma_delete_user_attribute_for_team or sigma_set_user_attribute_for_teams. It implies usage for revoking multiple team assignments but does not explicitly exclude alternatives or state conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the spec must include certain required fields, which is a validation behavior. However, it doesn't disclose other traits like failure modes, idempotency, or return behavior beyond what the output schema may provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex nested spec, the description is minimal. It doesn't explain the structure of pages/elements, how to obtain folderId/schemaVersion, or any prerequisites. Even though output schema exists, the input requirements are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is opaque (single spec object, 0% description coverage). The description compensates by listing required fields: name, folderId, schemaVersion, and pages with elements. This is critical but lacks details about types or structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a data model') and the input format ('from a JSON code representation'). It distinguishes from sibling tools like sigma_update_data_model and sigma_get_data_model by specifying creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. The description implies use for creating a new data model, but doesn't explicitly contrast with update or other creation tools. Sibling names provide context, but not within the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context (tableId scoping) but does not mention anything about return format or pagination, which is acceptable given the output schema exists. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word carries meaning, making it an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple one-parameter read-only tool with an output schema present, the description is sufficient. It clearly states the operation and the key input, and the sibling context clarifies the target resource. No significant gaps for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description compensates minimally by explaining that table_id refers to the warehouse table. It does not describe the format or how to obtain the tableId, but for a single simple parameter this provides just enough meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('columns for a warehouse table'), and a key identifier ('by its tableId'). This distinguishes it from sibling tools like sigma_list_workbook_columns or sigma_list_data_model_columns, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: when you have a tableId and need its columns, use this tool. However, there is no explicit guidance on when not to use it or alternatives such as sigma_list_workbook_columns, so the agent is left to infer the scope from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is known. The description simply says 'List', which aligns with the annotations, but adds no additional behavioral context such as pagination or filtering behavior. This meets the minimum bar for transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant information. Every word earns its place, and it is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, read-only, and an output schema is present (as noted in context), so the description does not need to explain return values. Given the annotations and output schema richness, the description provides adequate coverage for an agent to invoke the tool correctly, though it could mention any default ordering or scope, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter report_id, but the description's phrase 'for a report' gives implicit meaning to report_id as the identifier of the target report. The parameter title 'Report Id' is also self-explanatory, so the description partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('scheduled exports for a report'), clearly distinguishing it from sibling tools like sigma_list_workbook_schedules and sigma_list_materialization_schedules. The phrase 'for a report' narrows the scope to report-level schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus sigma_list_workbook_schedules or sigma_list_materialization_schedules. However, the description and tool name clearly imply that this is for report schedules, providing sufficient context for an agent to select it when dealing with report-level scheduled exports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds the semantic detail that bookmarks are saved filter states, but does not disclose additional behavioral traits like pagination or permission needs. This is adequate given the annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object. The parenthetical adds meaningful clarification without redundancy, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list tool with one parameter, clear annotations, and an output schema. The description sufficiently conveys the purpose and scope; the output schema covers return values, so no major contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required workbook_id parameter. The description does not explicitly explain that workbook_id identifies the target workbook or describe its expected format, so it fails to compensate for the schema's missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('bookmarks') and adds a parenthetical clarifying they are 'saved filter states.' This distinguishes it from sibling tools like sigma_add_workbook_bookmark and other workbook list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does and scoping it to 'a workbook,' but it provides no explicit when-to-use guidance, alternatives, or exclusions. It is not misleading, but it leaves the agent to infer when this listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with these. The description does not add any extra behavioral context such as pagination, filtering, or result details, but for a simple list operation the provided annotations and description are consistent and adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short declarative sentence with no filler. It front-loads the key verb and object, making it an efficiently structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with one required parameter, read-only annotations, and an output schema, the description provides enough context to understand the core function. It is slightly thin on when to use the tool relative to siblings, but overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter, workbook_id, with no description (0% coverage). The tool description says 'for a workbook,' which weakly implies the parameter's role, but does not explain how to obtain or format the ID. Since the parameter is self-explanatory, the description is minimally sufficient but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear object ('embed configurations for a workbook'), making the tool's purpose immediately obvious. It distinguishes itself from the sibling create tool (sigma_create_workbook_embed) and other list tools by identifying the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need embed configurations for a specific workbook. However, it does not explicitly state when to use this versus alternatives like sigma_create_workbook_embed or sigma_list_workbooks, nor does it provide any exclusions or additional usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the core safety profile. The description adds one useful behavioral clarification: the API expects a tag name, not an ID, preventing a common caller error. However, it does not disclose other behaviors such as whether the tag must exist, whether previous tags are replaced, or any side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word is informative. The second sentence provides a critical API detail without unnecessary fluff. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation (2 params, no nested objects) and the presence of an output schema, the description covers the essential action and the key parameter nuance. Annotations fill in safety and idempotency. It could be slightly more complete by noting whether the tag must already exist or whether this is a versioning action, but it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifies the tag_name parameter semantics ('takes the tag name here, not its ID'), which is valuable. However, it does not elaborate on data_model_id beyond its obvious meaning, and there is no guidance on allowed formats, tag existence, or relation to existing tags. Partial compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Apply a version tag to a data model', with a specific verb and resource. It differentiates from sibling tools like sigma_tag_workbook by explicitly targeting data models, and adds the key nuance that the tag is passed by name, not ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you need to apply a tag to a data model. However, it does not provide explicit guidance on when to use this tool versus alternative tagging tools (e.g., sigma_tag_workbook), nor does it mention any exclusions or prerequisites. The context is implied by the purpose statement, but not expanded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 context about the specific properties that can be updated (name, parentId), which is useful but goes little beyond the annotations. It does not disclose side effects, permissions, or reversibility, but given annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the tool's purpose and key parameters, and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a present output schema and adequate annotations, the description covers the essential use cases. It mentions the main updatable properties and the moving use case. Some details like behavior when 'body' is empty or optionality of parentId are not specified, but the presence of an output schema and annotations reduces the need for longer explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 of explaining parameters. It offers examples of what to put in 'body' (name, parentId), adding meaning beyond the schema's generic 'body' object. However, it does not explicitly explain 'inode_id' or the structure/requirements of 'body' beyond two example fields, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates file properties, with specific examples (name, parentId for moving). This distinguishes it from sibling tools like sigma_delete_file (which deletes) and sigma_create_folder (which creates). The verb 'update' plus resource 'file' makes 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying existing files, but does not explicitly state when to use it over alternatives (e.g., 'use sigma_delete_file to remove a file, not this'). No explicit exclusions or alternatives are mentioned, so usage is only implied by context and the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the context of 'pending' and the cross-organization source, implying a state change from pending to accepted. It does not detail side effects or permissions, but for a simple accept action this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, front-loaded with the verb and resource. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects) and the presence of an output schema, the description covers the core purpose. It could be more complete by indicating how to obtain the share_id, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'share_id'. While the parameter name is fairly self-explanatory (an ID for the share), the description fails to specify where to find this ID or any format. The description could have compensated by referencing list_shared_templates or explaining the ID's source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'accept' with a clear resource 'pending template share' and source 'another organization'. It distinguishes this from listing, creating, or saving templates among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use when you need to accept a pending template share from another organization. It does not explicitly state exclusions or alternatives, but the action itself is specific enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description reinforces this with 'DESTRUCTIVE.' It adds the operational requirement that confirm=True must be passed, which is critical because the schema defaults confirm to false. This extra context is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the action, the target, and the mandatory confirmation flag. No wasted words, and the most critical safety information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple deletion operation with a clear resource and a confirm flag. The description covers the destructive nature and the required confirmation. Since there is an output schema, the description does not need to elaborate on return values. Minor lack of explicit alternatives and parameter details keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning for the parameters. It only clarifies 'confirm' by saying 'Requires confirm=True.' The attribute_id and user_id parameters are left to their self-explanatory names, with no additional context about their role or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a clear resource ('user attribute assignment for a specific user'). It directly distinguishes itself from sibling tools like sigma_delete_user_attribute_for_team and sigma_delete_user_attribute_for_tenant by specifying 'for a specific user'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to remove a user attribute assignment for a particular user. It also provides an important usage requirement ('Requires confirm=True'), but it does not explicitly contrast with alternatives such as sigma_update_user_attribute_for_users or sigma_set_user_attribute_for_teams.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the base safety profile is covered. The word 'all' in the description adds slight context about the scope (returns the full list), but no other behavioral traits (e.g., pagination, ordering, or potential performance implications) are disclosed. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with a complete output schema, the description 'List all deployment policies' is fully complete. It clearly states what the tool does, and the output schema covers return values. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description adds no misleading information. With no params, no additional value is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all deployment policies' uses a specific verb 'list' and a clear resource 'deployment policies', distinguishing it from siblings like sigma_get_deployment (retrieves a single deployment) and sigma_create_deployment (creates one). It is unambiguous and directly tied to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, nor does it mention any exclusions or filters. Given the large sibling tool list, explicit context would help, but none is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds that it returns the complete list of tenants, implying automatic handling of pagination. This is valuable context beyond the annotations, though it could further clarify the absence of manual token parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the action, and every sentence provides relevant information: what it does, pagination model, and return value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (no parameters, output schema available, annotations present), the description is sufficient. It addresses the pagination mechanism and the complete-list behavior, though it could explicitly state that no page token input is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no burden on the description to explain them. The mention of nextPageToken is a bit ambiguous given the lack of a parameter, but the 'complete list' clause mitigates this by suggesting the tool handles pagination internally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tenants' with a specific resource and action, and adds the pagination model. It differentiates from offset-based pagination but does not explicitly name the sibling sigma_list_tenants tool, leaving some distinction to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the cursor-based pagination approach and contrasts it with offset-based pagination, implying the tool's purpose. However, it does not explicitly state when to use this tool over sigma_list_tenants or provide exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond the annotations: it creates the tag if it doesn't exist, and tag_color is ignored if the tag already exists. These side effects are not disclosed by the readOnlyHint or destructiveHint annotations, so the description meaningfully enriches the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured. The first sentence states the core purpose, and the second paragraph focuses on the tag_color parameter with all necessary details. Every sentence earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description covers the essential behavior and the key parameter nuance. It doesn't explain the exact response format, but the output schema fills that gap. It could mention how this differs from generic tagging, but that omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides thorough semantics for tag_color (allowed values, default, ignored if tag exists) and gives implicit meaning to workbook_id and tag_name via the operation description ('Promote a workbook by tagging it'). This is adequate, though it doesn't explicitly spell out each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Promote a workbook by tagging it (e.g., Production).' It uses a specific verb (promote) and resource (workbook), making the action unambiguous. However, it does not explicitly differentiate from sibling sigma_tag_workbook, so it loses a point for lacking explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when promoting a workbook to a status like Production. But it provides no explicit guidance on when not to use it, nor does it mention alternatives such as sigma_tag_workbook for general tagging. The usage context is clear but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the constraint that only 'public' embed_type is supported and clarifies conditional source_id requirement, but it does not disclose side effects like whether the embed becomes publicly accessible or how it can be removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and uses a compact bullet-like structure for parameter details. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and annotations, the description covers the key invocation parameters and constraints. It lacks some contextual detail about the embed's lifecycle, but overall is sufficient for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains embed_type, source_type, and source_id, including allowed values and conditional requirements. workbook_id is not described, but its purpose is clear from the name. This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an embed for a workbook' with a specific verb and resource. This distinguishes it from siblings like sigma_list_workbook_embeds and sigma_create_workbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when creating an embed, but it does not explicitly contrast it with alternative tools or state when not to use it. There is no mention of prerequisites or relationships to other embed-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds the critical behavior that the operation requires confirm=True, which is not in annotations and provides important safety context. However, it does not disclose other behavioral traits like reversibility or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with no fluff. It front-loads the core action and immediately highlights a crucial parameter requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, an output schema, and a simple action, the description covers the essential operational requirement (confirm=True). It lacks deeper context such as what 'deactivate' means practically or any preconditions, but for a straightforward destructive action with annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly explains the confirm parameter's purpose (required for deactivation) but provides no information about member_id beyond what the schema already shows. This partial compensation warrants a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deactivate a member' uses a specific verb and resource, clearly indicating the action. It is distinct from sibling tools like sigma_delete_team and sigma_update_member, and the mention of 'confirm=True' adds a key operational detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Requires confirm=True', which is a necessary precondition but lacks explicit comparison to alternatives or guidance on when to use this over other member management tools. The context is somewhat implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description goes beyond by explaining that confirm=True is mandatory, which is a safety behavior not captured by annotations. This adds valuable context about the confirmation safeguard 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no extraneous words. It delivers the essential information efficiently, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with an output schema and destructiveHint annotation, the description covers the core behavior and the confirmation requirement. The tool's simplicity and existing structured metadata make this level of detail sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description partially compensates by explaining the confirm parameter's requirement (must be true). However, it does not elaborate on team_id, leaving its meaning to be inferred from the parameter name. This is adequate but not fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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, distinguishing it from sibling delete tools like sigma_delete_workspace. The addition of 'Requires confirm=True' adds operational nuance without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a team needs to be deleted, and it provides the confirmation requirement as a usage condition. However, it does not explicitly mention alternatives or exclusions (e.g., when not to use it), leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so 'DESTRUCTIVE' is redundant. However, the description adds the behavioral requirement that confirm=True must be provided, which is a critical execution detail not in the annotations. It clarifies the scope by saying 'assignment'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a warning and requirement. No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with a simple schema, the description covers the action, destructive nature, and mandatory confirm flag. It lacks explicit side-effect disclosure, but with annotations and output schema, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description only explains the confirm parameter ('requires confirm=True'), while attribute_id and team_id are left to their names. The semantics are largely inferable from the tool name, but the description does not add meaningful guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the resource as 'a user attribute assignment for a specific team', distinguishing it from sibling tools like sigma_update_user_attribute_for_teams or sigma_delete_user_attribute_for_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a crucial requirement (confirm=True) but does not explicitly state when to choose this over alternative set/update/delete variants. The intended use is implied by the name and destructive warning, but no exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the safety profile is known. The description adds valuable behavioral info: the confirm flag must be true to execute the deletion. This is beyond what annotations provide, though it does not specify behavior when confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero fluff. It front-loads the action and includes the critical confirm requirement, making it an model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is sufficient. It identifies the necessary parameters (workbook_id and schedule_id) via schema, and the confirm gate is explicitly stated. The output schema covers return values, so no further details are needed. It misses only minor edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('Requires confirm=True'), but workbook_id and schedule_id are only implicitly understood from the tool name and context. The description adds some meaning but does not fully document all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a scheduled export, which is a specific verb and resource. This distinguishes it from sibling tools like sigma_list_workbook_schedules and sigma_add_workbook_schedule, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a key usage condition ('Requires confirm=True') but does not provide explicit guidance on when to use this tool versus alternatives. While the name and context imply its use for deleting schedules, it lacks a direct reference to list or create schedule tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context by stating that confirm=True is required, which is not apparent from the schema (confirm defaults to false). It does not contradict annotations, but does not describe long-term consequences or associated resource effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: 'Delete a workspace. Requires confirm=True.' Every sentence earns its place with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation, the description covers the essential requirement (confirm=True) and the resource being deleted. The output schema exists and annotations indicate destructive intent, reducing the need to explain return values. It omits details about irreversible consequences, but the simplicity of the tool and annotations make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 meaning to 'confirm' by explaining it must be true, which is critical. However, 'workspace_id' is not elaborated beyond its name, leaving the user to infer its source or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Delete a workspace'), clearly distinguishing it from sibling tools like sigma_delete_team and sigma_delete_file. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires confirm=True', which is a prerequisite for use, but gives no explicit guidance on when to use this tool versus alternatives or when not to use it. Sibling context suggests delete operations are distinct, but no alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds that the output is a JSON spec containing tables, columns, metrics, and relationships. This is useful behavioral context beyond what the annotations provide, though it does not mention rate limits, auth, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and output contents without redundant words. It is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and an existing output schema, the description is largely complete. It clearly conveys the tool's purpose and output. It could be improved by explicitly noting that this tool is for the raw spec vs. the general data model info, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the description does not explain data_model_id. However, the single parameter is self-explanatory from its name and the tool context, so the missing description is only a minor gap. The parameter is a straightforward string ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get' with a specific resource 'full code representation (JSON spec) of a data model' and enumerates what is included (tables, columns, metrics, relationships). This clearly distinguishes it from the sibling tool sigma_get_data_model, which likely returns metadata rather than the raw spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the JSON spec but does not explicitly contrast with sigma_get_data_model or state when not to use it. It provides context about the tool's purpose but omits exclusions or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavior context beyond the synonym and scope, but no additional traits like pagination or dataset size are disclosed. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose without any redundant words. Every word contributes to understanding, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter list tool with good annotations and an output schema, the description is sufficient. It specifies the resource and scope completely. A minor gap is the lack of explicit mention of pagination or whether 'all' truly means exhaustive, but the presence of an output schema mitigates the need for return-value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is fully covered (100%). The description adds value by clarifying that 'account types' are 'license types' and scoping to the organization, which helps the agent understand the output context even without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List all account types') and specifies the resource domain with a helpful synonym ('license types') and scope ('in the organization'). It distinctively identifies the resource type, differentiating it from the many sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool to retrieve account types. However, no explicit guidance is given on when to prefer it over alternatives or when not to use it. For a simple list tool, this is adequate but lacks explicit differentiation from other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context: it automatically follows pagination and returns ALL items organization-wide, providing insight into the operation's scale and handling of pagination 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function and key behavior with zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, reducing the need to explain returns and safety. However, the description lacks parameter semantics and explicit usage alternatives, and the optional parent_id creates ambiguity about what 'ALL' means. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 doesn't explain parent_id or type_filter. The parameter names give some hint, but their relationship to the 'ALL files/folders' scope is ambiguous (e.g., does parent_id restrict scope?). This leaves the agent guessing about semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ALL files/folders in the organization, with specific verb 'List' and resource 'files/folders'. It distinguishes from sibling sigma_list_files by emphasizing organization-wide scope and automatic pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an organization-wide list is needed, contrasting with folder-scoped listing. However, it doesn't explicitly mention alternatives or exclusions, so while context is clear, it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral details such as pagination, permission requirements, or ordering. It is consistent with the annotations but does not go beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one required parameter and annotations already stating safety, the description sufficiently covers the use case. The existence of an output schema presumably handles return value details, so the description need not elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter policy_id has 0% schema description coverage. The description implies policy_id references a deployment policy by saying 'in a deployment policy', which adds some meaning, but it does not explain the ID format, required values, or how to obtain one. This is a partial compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'documents' and a scope 'in a deployment policy'. This distinguishes it from sibling tools like sigma_list_deployments (which lists policies) and sigma_add_deployment_documents (which adds documents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the tool's purpose: retrieve documents for a given deployment policy. While it does not name alternatives or explicit when-not-to-use conditions, the context is unambiguous given the tool name and sibling list, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds the specific behavioral constraint that confirm must be set to true, which is not present in the annotations. This is valuable context because the schema's confirm parameter defaults to false, so the description prevents accidental destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains two short, information-dense sentences. It states the purpose and the single most critical usage requirement with no redundant or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential context: the action, the required confirmation, and the destructive nature (reinforced by annotations). The presence of an output schema means return values need not be described. Minor gaps include not describing what happens if confirm is false, but that is implied by the requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the confirm parameter's role ('Requires confirm=True') but does not describe workbook_id or tag_id. However, these parameter names are self-explanatory, and the description adds meaning to the confirm flag, which is the least obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pattern: 'Remove a tag from a workbook,' clearly distinguishing it from sibling tools like sigma_tag_workbook (adds tags) and sigma_get_workbook_tags (lists tags). The scope is unambiguous and the tool's name matches the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a critical usage requirement ('Requires confirm=True') but provides no guidance on when to use this tool versus alternatives like sigma_tag_workbook or sigma_delete_tag. There is no mention of prerequisites beyond confirmation, and no explicit exclusions or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, which covers the safety profile. The description adds behavioral context beyond annotations, including 'AI-powered semantic search' and 'Returns relevant doc passages with source URLs.' It also redundantly repeats 'read_only_hint: True', but that does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with three sentences, but it includes a redundant line 'read_only_hint: True' that duplicates the annotation. This adds noise without value, preventing a higher score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema, the description is quite complete. It specifies the tool's domain coverage and return type, and annotations cover safety. It does not mention limitations, but none are critical for a documentation search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'query' with no description, and the description provides 0% schema coverage. However, the description implicitly explains the parameter by saying 'Search Sigma Computing documentation' and 'Use this to answer questions about...' This implies the query is a natural language search string, but it does not explicitly define the parameter, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search Sigma Computing documentation using AI-powered semantic search.' It also specifies the output: 'Returns relevant doc passages with source URLs.' This distinguishes it from sibling tools like sigma_get_doc_page, which likely fetches a specific page, and sigma_formula_pitfalls, which is narrower in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this to answer questions about Sigma features, configuration, formulas, administration, embedding, and best practices.' This tells the agent when to invoke it, though it does not mention alternatives or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds the confirm=True requirement, which is valuable behavioral context. It also clarifies the destructive action as revocation, consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main action, and uses an example to clarify parameter format. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 destructive annotations; the description adds the confirm requirement and parameter example, making it reasonably complete. It doesn't describe return values, but the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains tenant_org_ids and the confirm requirement, but does not explain attribute_id. This partial compensation is helpful but leaves a gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool revokes a user attribute assignment for specific tenants, which is a specific verb+resource. It distinguishes from related sibling tools by focusing on revocation for multiple tenants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use it (to revoke assignments for specific tenants) but does not mention alternatives or exclusions. The confirm=True requirement is a clear precondition, but there is no guidance on choosing this over set or delete counterparts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description confirms a non-destructive, exploratory nature without contradicting. It adds that the tool covers both capabilities and limitations ('can and cannot do'), but does not disclose deeper behavioral details like response structure or error semantics. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence communicates the complete purpose without any filler or repetition. It is front-loaded and immediately clear, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete for invocation purposes. It clearly defines what the tool does (describe capabilities and limitations) and is sufficient for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description needs no parameter-level detail, and the baseline is 4. The input schema is empty, so there is nothing to add. The description correctly focuses on the tool's purpose rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Describe' with a clear resource ('what the Sigma REST API can and cannot do programmatically'), making the purpose unambiguous. It is distinct from sibling tools, which are all action-oriented for specific API operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when one needs an overview of API capabilities, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No direct contrast with sibling tools is provided, so guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, which cover the safety profile. The description adds minimal beyond annotations, merely confirming the 'all' scope. It does not disclose return format or pagination, but the output schema exists and the operation is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the action and resource, and the parenthetical adds valuable clarification without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with a full output schema and strong annotations, the description is complete. It needs no further detail about return values or behavior because the schema and annotations handle those aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It correctly implies the tool takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all API connectors'), with a clarifying parenthetical ('custom data integrations') that disambiguates from sibling tools like list_connections. It distinguishes itself from get_api_connector by explicitly indicating a list of all connectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all API connectors but provides no explicit when-to-use or alternatives. It doesn't mention when to prefer this over get_api_connector or list_connections, though the purpose is evident from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds domain context that these are 'rules for automatic source swapping on deployment'. This enriches understanding but does not disclose additional behavioral details such as pagination or whether results are sorted, so it adequately complements but does not exceed 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by a brief clarifying parenthetical. Every element earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a clear list action, and an output schema (indicated by the context signals), the description is fully sufficient. The parenthetical explains the domain purpose, making the tool's role in the broader API clear without needing additional return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so no parameter descriptions are needed. The description reinforces that the tool lists all policies without filters, aligning with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource 'source swap policies', then adds a parenthetical explaining their purpose. This distinguishes it from related sibling tools like sigma_get_source_swap_policy (singular) and sigma_create_source_swap_policy, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for enumerating all source swap policies, but does not explicitly state when to choose this over alternatives like sigma_get_source_swap_policy or the various swap tools. No exclusions or alternative tool mentions are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the organizational scope ('in the organization'), which is a useful behavioral detail beyond the tool name. No other behavioral traits (e.g., pagination, ordering) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It earns its place by stating exactly what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, open-world), the description is fully adequate. The presence of an output schema covers return value details, and the org-wide scope is clearly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no need for parameter explanations. The baseline for 0 parameters is 4, and the description appropriately adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all tags in the organization' uses a specific verb and resource, clearly distinguishing this from sibling tools like sigma_create_tag, sigma_delete_tag, and sigma_get_workbook_tags. It fully communicates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies the org-wide scope, providing clear context for when this tool is appropriate. However, it does not explicitly mention alternatives or when NOT to use it (e.g., for workbook-specific tags, sigma_get_workbook_tags would be used).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal extra context (organization scope) but discloses no additional behavioral traits such as pagination or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a comprehensive output schema, and strong annotations, the description is sufficient for a simple list operation. It provides the key scope (organization translation files) and nothing more is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description does not need to explain parameters, and the schema is empty, leaving nothing unclarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('organization translation files'), clearly stating what the tool does. It is distinct from all sibling tools, as no other tool references translations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are provided. The description implies the tool is used when you need to list translation files, but it does not state when to use it or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it lists 'all' attributes and mentions their purpose, but does not disclose additional behaviors such as pagination or response specifics. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by a concise parenthetical explaining the use case. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, list-all tool with an output schema, the description fully covers what the tool does and why it matters. The output schema handles return values, and the description provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description correctly avoids discussing parameters, which is appropriate since no parameters exist. This matches the baseline of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('user attributes') with the scope 'all'. It adds context by mentioning use in row-level security and dynamic parameters, distinguishing it from sibling tools that create or assign attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for RLS and dynamic parameters but does not explicitly state when to use this tool versus alternatives like sigma_get_user_attribute_users or sigma_create_user_attribute. It provides context but no exclusions or direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating a mutation. The description adds the distinction between connection and table-level swaps, but does not disclose potential side effects, permission requirements, or reversibility. With annotations present, this remains at a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and every word contributes. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for basic usage but leaves gaps: the structure of the mapping objects is unspecified, and there is no mention of prerequisites, side effects, or when to use sibling swap tools. Given an output schema exists for return values, the remaining gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the mapping parameters are open arrays of objects with no descriptions. The description compensates by distinguishing connectionMapping from sourceMapping, adding crucial semantics. However, it does not explain the expected structure of the mapping objects, so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Swap') and resource ('data sources on a report'), clearly distinguishing it from sibling swap tools for workbooks, templates, and data models. It also breaks down the two swap levels, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to use each mapping type: connectionMapping for connection-level swaps, sourceMapping for table-level swaps. This provides clear context for parameter selection, though it does not mention alternative sibling tools by name, leaving the 'vs alternatives' aspect implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal destructive behavior, but the description adds the important confirmation requirement ('Requires confirm=True'), which is not present in annotations. It reinforces the destructive nature with 'DESTRUCTIVE' in caps, giving the agent a clear warning. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a warning. It front-loads the core action ('Delete a grant from a connection path') and then highlights the destructive nature and confirmation requirement. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with 3 parameters, the description covers the essential aspects: what it deletes and the requirement for confirmation. Since an output schema exists, return values need not be explained. It does not mention prerequisites like permissions or whether the grant must exist, but these are less critical given the explicit confirmation flag. The tool is fairly complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifying that 'confirm=True' is required and by implicitly mapping 'connection path' to connection_path_id and 'grant' to grant_id. However, it does not explicitly describe each parameter or explain the default of confirm=false, leaving some ambiguity about whether confirm must be set to true for deletion to proceed. The parameter names themselves are self-descriptive, but the description could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (a grant from a connection path), making it distinct from sibling tools like sigma_add_connection_grant or sigma_delete_workspace_grant. The verb 'delete' plus target 'grant' and context 'connection path' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: deleting a grant from a connection path. It also gives a critical usage condition ('Requires confirm=True'), which is essential for successful invocation. However, it does not explicitly mention alternatives or exclusions, relying on the name to differentiate from related grant-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the requirement that confirm=True is necessary, which is a behavioral constraint beyond the schema's default. This prevents accidental deletion and aligns with the destructive nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'Delete a tag. Requires confirm=True.' Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters (one required) and an output schema available, the description covers the essential aspects: what the tool does and the mandatory confirmation. It does not elaborate on edge cases or error behavior, but for a simple delete operation, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 that confirm must be true, which clarifies the boolean parameter's role. However, tag_id is not described, but its meaning is apparent from the context. This partial compensation yields a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a tag.' which uses a specific verb (delete) and resource (tag). This clearly distinguishes it from sibling tools like sigma_delete_file and sigma_delete_workspace, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage guideline: 'Requires confirm=True.' This tells the agent that the confirm parameter must be set to true for the deletion to proceed. It does not explicitly mention alternatives, but the resource is unambiguous, and the confirm requirement is valuable operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the confirm=True requirement and reinforces the destructive nature, which is useful beyond the structured metadata. It doesn't contradict annotations; it complements them with the confirmation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: purpose, destructive warning, and confirmation requirement. Every word earns its place, with the most critical information front-loaded. There is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 3 parameters and an output schema, the description covers the essential purpose, destructive nature, and confirmation requirement. It doesn't explain return values, but an output schema exists, so that's acceptable. Slight gap: no detail on what 'assignment' means or whether deletion is reversible, but given the annotations and simple scope, it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifies that tenant_org_id refers to 'a specific tenant' and mentions confirm=True, but it doesn't explain attribute_id beyond its name. The schema provides titles and types, so the description adds some but not enough context to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Delete'), the resource ('user attribute assignment'), and the scope ('for a specific tenant'). This distinguishes it from sibling tools like sigma_delete_user_attribute_for_user and sigma_delete_user_attribute_for_team, and from set/update variants for tenants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'DESTRUCTIVE' and 'Requires confirm=True', providing clear context for when this tool should be used (for destructive tenant-scoped deletions) and an explicit prerequisite (confirmation). It doesn't name alternative tools explicitly, but the purpose clarity implies the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the return is 'full page content' in Markdown, but does not mention error behavior, rate limits, or other edge cases. This matches the baseline expectation when annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action. The second sentence provides useful examples. The 'read_only_hint: True' line is redundant with annotations, but it does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only fetch tool with one parameter and an output schema, the description is complete. It states what is returned ('full page content') and how to target the page. No additional context is needed given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's page_slug parameter has no description, and coverage is 0%. The description compensates by explaining it accepts a slug or section path and gives examples ('create-a-workbook', 'docs/create-a-workbook'). This adds meaningful semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), identifies the resource ('Sigma documentation page'), and specifies the output format ('clean Markdown'). It distinguishes from siblings by focusing on fetching a specific page via slug or path, unlike sigma_search_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear guidance is given on what to pass (page slug or section path) with concrete examples. It does not explicitly state when not to use this tool or name alternatives, but the use case is straightforward and well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by specifying the return content ('formulas and types') and the execution scope ('across all elements'), which goes beyond the structured annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the verb and immediately specifies the resource and scope, and every phrase ('including formulas and types') adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are inherently documented. The description covers the scope and key return content, and annotations handle the read-only behavior. The only minor gap is lack of mention of permissions or pagination, but for a straightforward list operation this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter workbook_id is self-explanatory by name, and the description implies it identifies the target workbook. However, the schema has zero description coverage (0%), and the tool description does not elaborate on the parameter's format, how to obtain it, or any constraints. The name carries the meaning, but with low schema coverage, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List'), the resource ('columns across all elements in a workbook'), and adds distinctive detail ('including formulas and types'). This differentiates it from sibling tools like sigma_get_element_columns (which targets a single element) and sigma_list_workbook_elements (which lists elements, not columns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all elements' provides clear context that this is a comprehensive, workbook-wide listing, implying it is appropriate when you need all columns rather than a single element's columns. However, it does not explicitly name alternatives or state when not to use it, so it falls short of an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate that. The description adds minimal extra behavioral context—it doesn't mention side effects, permissions, or reversibility of the swap. It relies on the openWorldHint to imply broader impact. This is adequate but not rich; it's neither contradictory nor highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the primary verb and object. Every sentence provides value, and there is no wasted wording or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of a swap operation and the existence of an output schema, the description covers the essential distinction between connection-level and table-level swaps. It's not overly verbose, but it could briefly mention prerequisites or effects on dependent workbook elements. Still, it's sufficiently complete for an agent to select the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning by explaining the two mapping parameters: 'connectionMapping' for connection-level swaps and 'sourceMapping' for table-level swaps. This compensates well for the bare schema, though workbook_id is left unexplained (but its purpose is self-evident from its name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Swap data sources for a workbook.' This includes a specific verb (swap), resource (data sources), and scope (for a workbook). It distinguishes from sibling tools like sigma_swap_report_sources and sigma_swap_data_model_sources by explicitly naming workbooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for swapping workbook data sources and even offers guidance on parameter selection: 'Use connectionMapping for connection-level swaps, sourceMapping for table-level swaps.' However, it does not explicitly mention when to use this tool over alternatives like sigma_swap_report_sources or sigma_swap_template_sources, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds the critical behavioral trait of full replacement via PUT, which is not in annotations. Annotations already indicate non-read-only, and the description clarifies the mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, directly states the operation and key mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations handle safety, the description covers the essential behavior. It could mention implications of full replacement (e.g., fields not in spec are removed), but that's inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description explains that the input is a JSON code representation, which maps to the 'spec' parameter. It doesn't elaborate on data_model_id or format details, so partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the target (existing data model), and the method (full replacement via PUT), distinguishing it from create/get operations in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when you need to replace an existing data model's full definition. It doesn't explicitly name alternatives like sigma_create_data_model, but the 'existing' and 'full replacement' language provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the key behavioral detail that the conversion is one-way and produces a new report, going beyond the annotation information. It does not detail all side effects but adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by a compact parameter list. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool has only three simple parameters, the description covers purpose, key behavior, and parameters sufficiently. It lacks some context like prerequisites or permissions, but overall it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 parameter understanding. It explicitly explains workbook_id, name (required by API), and destination_folder_id (optional with default), significantly enhancing the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts a workbook to a report, emphasizing it is one-way and creates a new report. This specific verb+resource combination distinguishes it from related tools like sigma_create_report or sigma_duplicate_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'one-way, creates a new report' but does not explicitly mention when to use this tool over alternatives or provide exclusions. It gives enough context to infer a typical conversion scenario but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds the requirement for confirm=True, which is crucial for safety, and clarifies the resource identification method. It does not conflict with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence conveys the action, target, and safety condition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with only two parameters, the description covers the essential invocation details and the confirmation requirement. The presence of an output schema means return values don't need elaboration. However, it does not mention any side effects or related resources, though annotations hint at destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: inode_id is the identifier for the resource and confirm must be set to true. This provides clear meaning beyond the bare schema labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the resource class ('file/workbook/data model') plus the identifier method ('inode ID'). It clearly distinguishes from sibling delete tools like sigma_delete_workspace or sigma_delete_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a hard prerequisite ('Requires confirm=True') but gives no explicit guidance on when to prefer this tool over alternatives or when not to use it. The resource scope is implied by the description, but there is no direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read, non-destructive operation. The description adds value by noting the destination_folder_id defaults to the original folder and that name is required by the API. It does not contradict annotations, and provides useful behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a one-sentence summary followed by three line-item parameter explanations. Every sentence adds functional value with no redundancy or filler. It is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and all parameters, and an output schema exists to describe return values. It could mention that the original workbook remains unchanged or that permissions are copied, but given the annotations (non-destructive, open-world) and output schema, the description is sufficiently complete for a cloning operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 as the ID to clone, name as the required new name, and destination_folder_id with its default behavior. This adds meaning beyond property names and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Duplicate an existing workbook' which is a specific verb+resource combination. It clearly distinguishes this from creation (sigma_create_workbook) or copying to another member (sigma_copy_workbook_to_member) by focusing on cloning an existing workbook. The parameter explanations further clarify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the parameters (workbook_id, name, destination_folder_id), but does not explicitly provide when-to-use vs alternatives or exclusions. It lacks guidance such as 'Use this when you want a copy of an existing workbook rather than creating from scratch.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, setting the safety baseline. The description adds the contextual scope (templates from other orgs) but does not disclose other behaviors like pagination or return format. This is acceptable for a simple list tool but adds only modest value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List templates shared with your organization from other orgs.' It conveys the action, subject, and scope without any redundant or unclear wording. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters, an output schema, and clear annotations, this description is fully sufficient. It states what is listed and the scope, and the output schema covers return values. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no constraints to explain. The description clarifies the semantic scope of what is being listed (shared templates from other orgs), which aids understanding. With 0 parameters, the baseline is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'templates shared with your organization from other orgs.' This distinguishes it from sibling tools like sigma_list_templates (which likely lists the org's own templates) and sigma_accept_shared_template. The scope is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you want to see templates shared by other organizations. It provides context but does not explicitly mention alternative tools or when not to use it. However, the phrasing is specific enough that an agent can infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds value by stating that 'confirm=True' is required, which is a behavioral prerequisite not captured in annotations. It also clarifies that the operation removes assignments, giving more context than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, parameter details, an example, and usage alternatives. Each sentence contributes value. It is slightly longer than minimal, but the length is justified by the need to explain parameters and the alternative tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations (destructiveHint), and the presence of an output schema, the description provides sufficient context. It explains the required confirm flag, the exact effect (removing assignments), and how to reverse it, making the tool's behavior clear. No major gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explain user_ids with an example and notes the confirm requirement. However, attribute_id is not explicitly described; its purpose is only implied by the tool name and context. This leaves a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Revoke a user attribute assignment for specific users.' This uses a specific verb ('revoke') plus resource ('user attribute assignment') and target ('specific users'). It distinguishes itself from sibling tools like sigma_set_user_attribute_for_users, which assigns rather than revokes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool vs alternatives: 'To assign (not revoke), use sigma_set_user_attribute_for_users instead.' It also mentions a workaround for a direct POST endpoint. This clearly differentiates the use case and gives a concrete alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, and the description adds valuable behavioral detail: it polls until ready, returns base64 content, and has a max_bytes limit with a specific fallback behavior. This goes beyond the basic annotation profile without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. Each sentence adds meaningful detail—purpose, polling, format/layout constraints, parameter overrides, max_bytes behavior, and response encoding—with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to detail return structures. It covers the core behavioral context: async polling, format/layout restrictions, parameter overrides, and size limits. It does not mention timeout behavior explicitly, but the polling statement implies it, so the description is largely complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description compensates well by explaining format, layout, parameters overrides, and max_bytes. It omits explicit descriptions for element_id, workbook_id, and timeout_seconds, but these are reasonably inferable from the tool name and the 'polls until ready' hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Export a workbook/element and download the result'. It immediately distinguishes itself from sibling export tools by including 'download' and the polling behavior. The format options further clarify its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to export and download with polling, plus parameter constraints. However, it does not explicitly name alternatives (e.g., sigma_export_workbook, sigma_export_report) or exclusion criteria, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the description does not need to restate those. It adds behavioral context by using 'Force' and explaining the empty-list behavior for full sync, which implies a side-effectful operation. This is sufficient for a simple sync tool; no contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the action ('Force Sigma to re-index') and immediately provides the key parameter behavior. Every word earns its place, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two parameters, one required), the description covers the essential context for invocation. An output schema is present, so return values do not need to be described. Some details like the effect scope or whether null versus empty list differs could be added, but for this complexity level the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the most important parameter nuance: passing an empty list for `path` triggers a full sync. It does not explain `connection_id`, but that parameter is self-evident from the tool name and schema. The added meaning goes beyond the raw schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource combination, 'Force Sigma to re-index a warehouse path,' which clearly states what the tool does. It distinguishes itself from sibling tools like sigma_test_connection or sigma_sync_all_tables_in_schema by focusing on re-indexing a specific warehouse path. 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for forcing a re-index of a warehouse path. It also gives a key usage instruction: 'Pass empty list for full sync.' However, it does not explicitly mention alternatives or exclusions compared to related sync tools, though this is not critical given the specific focus. Overall, the usage intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior. The description adds value by specifying 'current authenticated user', indicating that authentication is required and the response is scoped to the caller. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters), strong annotations (readOnly, non-destructive), and presence of an output schema, the description fully covers the necessary context. There are no ambiguous inputs or missing behavioral warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and no additional semantic information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'current authenticated user' and scope 'details', clearly distinguishing it from sibling tools like sigma_get_member or sigma_get_tenant. It precisely identifies the target of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when the agent needs information about the caller's own user context. However, it does not explicitly mention exclusions or alternatives (e.g., 'for other users use sigma_get_member'), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds the key behavioral trait of automatically following pagination, which is valuable context beyond the annotations, though it stops short of mentioning potential performance impacts or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, and includes the crucial pagination behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema present, the description fully covers purpose and behavior. It clearly defines the scope (organization-wide) and the automatic pagination, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. Baseline for 0 params is 4, and the description appropriately requires no additional parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all data models in the organization, with a specific verb ('List') and resource ('data models'). The emphasis on 'ALL' and 'automatically following pagination' distinguishes it from sibling sigma_list_data_models, which likely returns a single page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a complete set of data models is needed, but it does not explicitly name alternatives or exclusions. It clearly conveys that this tool handles pagination automatically, which is sufficient context for selecting it over a non-paginated list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it collects errors from individual workbooks/pages rather than failing silently, which is non-obvious. It also describes the return context (workbook, page, element).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: action, result, and error handling. Every sentence adds distinct information without redundancy, and the most important statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters), and an output schema exists, so return values are already structured. The description supplements by noting error collection, making it adequately complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, there is nothing for the description to clarify. The baseline of 4 applies since the description doesn't introduce parameter-related confusion or omit any required details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scan all workbooks to find input-table elements', using a specific verb and resource. It distinguishes from sibling tools like sigma_list_workbook_elements by specifying 'all workbooks' and focusing specifically on input-table elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool scans across all workbooks, implying its use for global discovery. However, it does not explicitly contrast with alternatives such as sigma_list_workbook_elements or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations: it automatically follows pagination, meaning the agent can expect a complete result set without manual pagination loops. This is a meaningful disclosure for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List ALL members in the organization, automatically following pagination.' Every word contributes meaning, with no fluff or repetition. It captures the purpose and key behavioral nuance in an extremely compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema present, the description covers everything needed: scope (all members in the organization) and a pivotal behavior (automatic pagination). There is no additional context that would be expected, and the output format is presumably documented by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is fully self-explanatory. The description adds no parameter information (and doesn't need to), so the baseline of 4 for no-parameter tools applies. The absence of parameters is clear from the input schema, and the description correctly focuses on behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('List'), a resource ('members in the organization'), and a scope ('ALL'), instantly differentiating from sibling tools like sigma_list_team_members and sigma_list_members. The emphasis on 'automatically following pagination' further distinguishes this as the comprehensive listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool: when you need all members and want pagination handled automatically. It doesn't explicitly mention alternatives or exclusions, but the 'ALL' and 'automatically following pagination' signals provide clear context that this is for exhaustive retrieval rather than a page-based or scoped listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context by stating that pagination is automatically followed. This is a non-obvious implementation detail that affects how the agent can use the results. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information without redundancy. Every word ('List', 'ALL', 'reports', 'organization', 'automatically following pagination') contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list operation with an output schema and safety annotations, the description fully covers the tool's function and key behavior (automatic pagination). No further details are necessary, as return values are specified by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter details to add. According to the rubric, a baseline of 4 applies when there are no parameters, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), resource ('all reports'), and scope ('in the organization'). It distinguishes itself from sibling tools like sigma_list_reports by emphasizing 'ALL' and 'automatically following pagination', indicating a comprehensive listing without manual page handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving the complete set of reports without needing to process pagination manually. It provides clear context for when to use it, but does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates a safe read operation, and the description adds valuable behavioral context by stating that pagination is handled automatically. It discloses that the tool will fetch all pages, which is a non-obvious behavior not captured by the empty input schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('List ALL teams') and then adds the key behavioral detail. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema present and clear sibling context, the description is fully complete. It covers the essential distinction (ALL teams + automatic pagination) and requires no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema description coverage is 100%, so baseline is 4. The description adds no parameter-specific details, but none are needed; it focuses on the scope and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ALL teams in the organization and explicitly mentions automatic pagination, which distinguishes it from siblings like sigma_list_teams that likely return a single page. The verb 'List' and resource 'teams' are specific, with scope 'ALL' adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: when you need a complete list of all teams without manual pagination. It does not explicitly name alternatives or exclusions, but the 'ALL' and 'automatically following pagination' implies this is the comprehensive listing tool versus a paged one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavior: automatic pagination and full organizational scope, implying potentially large data retrieval and multiple API calls. This goes beyond the annotations and gives the agent useful expectations about execution cost and output volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'List ALL workbooks in the organization, automatically following pagination.' It is front-loaded with the action and scope, and every word adds value. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list-all tool with an output schema and clear annotations, the description is complete. It tells the agent exactly what the tool does (list all workbooks), its scope (organization), and a key behavior (auto-pagination). The output schema covers return values, so no further description is needed. This is a fully self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Per the baseline for 0 parameters, a score of 4 is appropriate. The description adds nothing about parameters because there are none, but it correctly emphasizes the tool's all-encompassing scope, which is the only 'semantic' aspect relevant for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List ALL workbooks in the organization' with a specific verb ('List') and resource ('workbooks'). The use of 'ALL' and 'organization' distinguishes it from siblings like sigma_list_workbooks, which likely offers filtered or paginated listing. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieve every workbook without manual pagination. While it does not explicitly compare to alternatives, the emphasis on 'ALL' and 'automatically following pagination' provides clear context for when this tool is appropriate. Given the sibling sigma_list_workbooks, the differentiation is evident even if not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond annotations by explaining the cross-referencing mechanism ('Cross-references member's file list against the full workbook catalog') and notes the output includes 'full workbook metadata'. This adds useful insight into how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and the second sentence adds valuable context about the underlying logic. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter, the description adequately explains the tool's purpose and mechanism. Annotations cover safety, and an output schema is present (implied), so the lack of return format details is not a gap. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but there is only one parameter, member_id, and the description's phrasing 'accessible to a member' makes the parameter's purpose clear. The description does not add format details, but the parameter is self-explanatory and required, so the lack of explicit mention is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists workbooks accessible to a specific member, with a specific verb ('List') and resource ('workbooks accessible to a member'). It distinguishes from sibling tools like sigma_list_workbooks (all workbooks) and sigma_list_files by scoping to member accessibility and mentioning full metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to find all workbooks a member can access. It does not explicitly name alternatives or exclusions, but the phrasing makes the specific use case clear. Sibling tools for listing workbooks exist, but the member-scoping is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a non-obvious API detail: 'The Sigma API takes the tag name here, not its ID.' This goes beyond the annotations, which only indicate the tool is not read-only and is idempotent. It helps prevent a common mistake and provides useful behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word adds value. The first sentence states the purpose; the second clarifies a potential pitfall. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter tool with an output schema and annotations covering safety and idempotency. The description fully covers the purpose, the key parameter quirk, and enough context for correct invocation. There is no obvious missing information needed for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema descriptions, the description compensates by clarifying the `tag_name` parameter (it's the tag name, not an ID) and provides an example ('Production'). The `workbook_id` parameter is not explained, but its meaning is apparent from the name and context. The description adds significant meaning for a critical parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Apply a version tag to a workbook', with a specific verb and resource. It also distinguishes itself from siblings like sigma_remove_workbook_tag and sigma_tag_data_model by the explicit mention of 'workbook' and 'tag by NAME'. The additional note about the API taking the tag name, not its ID, further clarifies the tool's specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for usage: when you want to apply a tag to a workbook. It implicitly tells you to use this tool over sigma_remove_workbook_tag (which removes) and sigma_tag_data_model (which tags a different resource). However, it does not explicitly mention alternatives or exclusions, so it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds value by disclosing the token-efficiency behavior of summary_only=True, which is not evident from the schema. This goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. The first states the core purpose, the second provides a parameter usage tip. No waste, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional boolean parameter, and the description covers purpose and parameter behavior. Output schema and annotations provide additional context, so nothing else is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the only parameter, summary_only, by stating 'Pass summary_only=True for concise token-efficient response.' This compensates for the 0% schema description coverage and adds practical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all connections in the Sigma organization' with a specific verb and resource, and the scope is unambiguous. It distinguishes from siblings like sigma_get_connection (single connection) by emphasizing 'all connections'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 you need all connections in the organization. It does not explicitly mention alternatives or exclusions, but the context is clear enough. The additional tip about summary_only parameter provides practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations, the description discloses the step-by-step process: resolving by email, finding all workbooks owned, PATCHing each, and the dry_run behavior that reports changes without applying them. This gives clear side-effect and safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first is a clear one-line purpose, the second explains the process and dry-run semantics. No filler or redundancy; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, resolution mechanism, and dry-run behavior, which is sufficient for a mutation tool with an output schema. It omits edge-case details like missing members, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that old_owner_email and new_owner_email are used to resolve members, and dry_run (default true) controls whether changes are made. This adds meaning to all three parameters, though it doesn't cover error cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer all workbooks from one member to another' with a specific verb and resource. It further distinguishes itself from siblings by explaining the reassignment mechanism, making it unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to transfer all workbooks from one member to another, and the dry_run default offers a safe usage pattern. However, it lacks explicit exclusions or comparisons to alternatives like sigma_copy_workbook_to_member.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context by listing the exact knowledge domains covered (NULL handling, aggregate vs row-level, etc.), which helps the agent set expectations about the tool's content beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that front-load the core purpose and list key topics, followed by a clear usage directive. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description provides enough context. It states the tool's purpose, scope, and when to use it, making it self-sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameters, and there is no parameter information missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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, with a specific action verb ('Return') and resource. It enumerates covered topics (column syntax, NULL handling, etc.), distinguishing it from all sibling tools that perform CRUD or listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this before writing any Sigma formula expression.' This tells the agent exactly when to invoke the tool, and since no sibling serves a similar reference role, no alternatives are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-sigma MCP server](https://glama.ai/mcp/servers/christianclaudio/mcp-server-sigma/badges/card.svg)](https://glama.ai/mcp/servers/christianclaudio/mcp-server-sigma)

Score Badge

Copy to your README.md:

[![mcp-server-sigma MCP server](https://glama.ai/mcp/servers/christianclaudio/mcp-server-sigma/badges/score.svg)](https://glama.ai/mcp/servers/christianclaudio/mcp-server-sigma)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/christianclaudio/mcp-server-sigma'

If you have feedback or need assistance with the MCP directory API, please join our Discord server