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

No annotations are provided, so the description carries the full burden. It only states the delete/cancel action, but does not disclose that the operation is destructive, irreversible, or that it may fail for already-approved requests. It lacks any behavioral context such as permissions required, side effects, or response format.

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

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

The description is two short sentences, front-loaded with the action. It is concise but repeats the same meaning in Persian and English, which is slightly redundant but not harmful. There is no unnecessary fluff.

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

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

For a destructive tool, important context is missing: no mention of which request statuses can be deleted, whether deletion is reversible, or what happens to related approvals. The output schema exists, so return format is covered, but the description lacks operational constraints and failure scenarios.

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

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

Schema coverage is 100% with descriptions for all parameters, including doc_id from kasra_get_submitted_requests and doc_type_id defaults. The description itself adds no parameter guidance beyond what the schema provides. Baseline of 3 applies because the schema is thorough.

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

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

The description clearly states the action: 'Cancel or delete a submitted permission, leave, mission, or remote work request.' This is a specific verb+resource combination. It differentiates from the submit tool by the delete/cancel verb, though it doesn't explicitly name the sibling. The bilingual text adds clarity for Persian-speaking agents.

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

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

The description implies usage when the user wants to cancel a previously submitted request, but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions (e.g., only for pending requests). There is no mention of prerequisites like authentication or status restrictions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state the output format and delivery mechanism (Excel .xls and direct download link), but it does not mention side effects, authorization requirements, file availability duration, or whether any state is changed. Exporting a report is likely read-only, but this is not explicitly disclosed.

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

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

The description is concise and front-loaded, with two short sentences conveying the essential purpose and output format. There is no redundant or filler content; every clause adds relevant information.

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

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

Given a simple tool with three optional parameters, full schema coverage, and an output schema present, the description is largely sufficient for an agent to call it correctly. It could be improved by clarifying when to prefer this over kasra_get_daily_report and by noting any behavioral caveats, but nothing critical is missing for basic invocation.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds no extra meaning about date formats, defaults, or how the parameters affect the report, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action ('Export daily attendance report') and output format ('Excel spreadsheet file (.xls) with direct download link'). This distinguishes it from sibling tools like kasra_get_daily_report, which presumably returns data rather than a downloadable file.

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

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

The description makes it clear the tool is for obtaining an Excel export with a direct download link, which is enough context for an agent to choose it over data-returning siblings. It does not explicitly name alternatives or provide when-not-to-use conditions, but the distinct file-delivery behavior gives clear usage context.

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

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

There are no annotations, so the description carries the disclosure burden. It does identify the operation as read-only ('view') and scopes it to received workflow items, but it does not state extra behavioral constraints such as whether only the caller's items are shown, whether the tab parameter changes the result set, or whether any side effects occur; the schema covers some of this, but the description itself 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.

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

The description is one short sentence with the verb and resource front-loaded and a useful clarifying parenthetical. There is no filler or redundant restatement of the tool name.

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

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

For a low-complexity read-only tool with an output schema and fully documented optional parameters, the description covers the core semantics (what the cartable contains and why it is used). A brief pointer distinguishing this from kasra_get_submitted_requests would make it fully complete, but nothing required to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% and the tab parameter already documents its default and four options, so the schema carries the parameter semantics. The description adds no parameter-level meaning; the baseline of 3 applies.

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

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

The description uses a concrete verb ('مشاهده' / view) with a specific resource: workflow cartable documents and requests, including incoming items for review, approval, or referral. This makes the purpose clear and broadly separates it from sibling tools, though it never explicitly contrasts with the similar-sounding kasra_get_submitted_requests.

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

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

The parenthetical ('اسناد دریافتی برای بررسی، تأیید یا ارجاع') implies that the tool is for inspecting workflow items that need user action. There is no explicit when-to-use or when-not-to-use guidance nor any named alternative, so an agent must infer the boundary from the description alone.

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

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

With no annotations, the description carries the burden of behavioral disclosure; it does convey a read-only lookup and specifies the content of the returned list. However, it does not explicitly state that the call has no side effects, nor does it explain whether the optional `reason` parameter affects the result, so some behavior is left to inference.

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

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

The description opens with a clear one-sentence summary and then organizes details into compact category lines with system codes, making it easy to scan. The ellipses and repeated examples add a little redundancy, but the overall structure is efficient and useful.

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

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

The description adequately explains what the tool returns and even previews the main categories, which is helpful given that an output schema exists. It leaves the `reason` parameter unexplained and does not connect the tool to the larger credit-request workflow, so it is viable but not fully complete.

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

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

The only parameter, `reason`, is undocumented in both the schema and the description, and schema coverage is 0%. The phrase 'complete list' weakly implies the result is not filtered, but the description never explains what `reason` means or how it should be supplied, so it fails to add semantic value for the parameter.

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

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

The description states a specific action and resource: it retrieves the complete list of credit types (leaves, missions, overtime) with their system codes. It further distinguishes itself by enumerating concrete categories and examples, so it is clearly separate from siblings like `kasra_submit_credit_request` or `kasra_get_dashboard_summary`.

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

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

The description clearly frames the tool as a catalog lookup for credit type codes and categories, which makes the appropriate usage context evident. It does not explicitly name alternatives or state when not to use it, but for a simple reference-data getter the context is clear enough.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It implicitly signals a read-only operation via 'دریافت' and gives a detailed inventory of output content, including the total-period row. However, it does not mention authorization needs, default date-range behavior, or any side effects—though for a GET-style report tool the omission is not severe.

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

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

The description is front-loaded with the main purpose and uses a compact bullet list to enumerate output fields. Each bullet adds distinct, non-redundant information, and the note about the total row is useful. There is no filler or repetition.

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

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

With no required parameters and an output schema present, the description's detailed field inventory is more than sufficient for an agent to understand what will be returned. The main gap is the lack of guidance about default date behavior and relative selection among sibling reports, but the schema and output schema cover most practical calling needs.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter-level semantics beyond what the schema already provides for start_date, end_date, and reason. The fields are adequately documented in the schema itself.

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

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

The description clearly states the verb 'دریافت' (retrieve) and the resource: a detailed daily attendance/traffic report. It enumerates the specific fields included (presence, absences, punches, leaves, missions, remote work), and the word 'روزانه' (daily) distinguishes it from sibling tools like kasra_get_monthly_report.

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

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

No explicit guidance is given about when to use this tool versus alternatives such as kasra_get_monthly_report, kasra_get_dashboard_summary, or kasra_export_daily_report_excel. The only implicit cue is 'daily' in the name and description, which is not sufficient routing guidance.

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

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

With no annotations, the description must carry the burden. It lists what data is included, but it doesn't mention whether the operation is read-only, any required prerequisites (e.g., authentication), or behavior limits. It's clear it's a lookup, but details like data freshness or error conditions are absent.

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

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

The description is structured as a bulleted list followed by a concise English summary. It is informative without excessive length, though the dual-language repetition adds slight redundancy.

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

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

Given the tool's complexity (multiple data points), the description covers the main outputs. With no output schema details (though indicated as present), the description compensates by listing the included items. It's complete enough for a dashboard summary, but doesn't specify exact return format or data types.

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

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

The sole parameter 'reason' is not documented in the description (schema coverage 0%), but since it's optional with a default of null, the agent likely doesn't need to set it. The description covers what the tool returns, so the parameter's purpose, likely a justification or audit trail, is not explained, but this is a minor gap.

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

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

The description clearly states that the tool retrieves a dashboard summary with a detailed list of included items (punch, cardex, hours, permissions, requests). This differentiates it from siblings that focus on specific aspects like daily report or punch gaps.

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

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

The description implies use when a broad overview of attendance and status is needed, but it doesn't explicitly state when not to use it or direct to alternatives for more detailed data. The sibling context suggests alternatives, but the description itself lacks comparative guidance.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not explicitly address side-effect profile, authorization requirements, rate limits, or behavior related to the optional 'reason' parameter. This is a moderate gap for a simple getter.

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

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

The description is short and front-loaded, stating the resource immediately. The bilingual duplication is mildly redundant but not excessive, and every substantive clause contributes to identifying the tool's purpose.

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

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

For a simple getter with an output schema, the core resource is identified and basic invocation is possible. However, the undefined 'reason' parameter and the lack of differentiation from sibling retrieval tools leave meaningful gaps in the agent's ability to use this tool correctly in context.

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

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

The only parameter, 'reason', has 0% schema description coverage and is not mentioned anywhere in the tool description. An agent has no way to determine whether the parameter is required, what values it accepts, or what effect it has on the result.

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

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

The description states a specific verb ('Get') and a specific resource ('user desktop shortcuts and bookmarked pages'), making the target clear. However, it does not differentiate itself from sibling tools like kasra_get_user_menu or kasra_get_dashboard_summary, so it narrowly misses the top score.

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

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

There is no guidance about when to invoke this tool or when to prefer an alternative. The description only restates what the tool retrieves, leaving the agent to infer usage context from the name and siblings.

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

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

With no annotations, the description carries the full burden. It discloses that it returns holidays for the year, which is a scope detail. However, it does not explicitly mention that the operation is read-only, nor does it address any potential side effects, authentication, or rate limits. The behavior is implied by the 'get' verb but not explicitly stated.

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

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

The description is concise, using two sentences (Persian and English) to state the purpose. It is front-loaded and contains no unnecessary fluff.

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

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

The description provides the core purpose but omits explanation of the 'reason' parameter and any context about how the year is determined. Given that an output schema exists, return format is covered, but the parameter and any usage constraints are missing.

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

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

The schema has one optional parameter 'reason' with no description (0% coverage). The description does not mention this parameter at all, leaving its purpose and expected format entirely undefined. The agent has no information about what to pass for 'reason'.

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

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

The description clearly states that this tool retrieves official calendar holidays for the year. It uses a specific verb (get) and resource (holidays), and is distinct from sibling tools like kasra_get_profile or kasra_get_daily_report which serve different purposes.

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

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

The description provides no explicit guidance on when to use this tool over alternatives. It only states what it does, implying usage when holiday data is needed, but does not mention any exclusions or alternative tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions current-user scope but does not disclose whether the operation is read-only, marks messages as read, has side effects, or requires authentication. The word 'get' implies read-only but is not explicit.

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

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

The description is short and front-loaded, with the Persian and English translations carrying the same information. It is efficient, though the duplicated translation adds slight redundancy.

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

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

For a simple getter with zero required parameters, the description gives enough to recognize what the tool returns. However, the undocumented 'reason' parameter and absence of usage guidance leave meaningful gaps.

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

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

The schema has one optional parameter 'reason' with 0% schema description coverage, and the description does not mention it at all. The agent has no way to know what value to provide or whether it affects the result.

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

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

The description uses a specific verb ('get') and clearly names the resource ('user notifications, broadcast messages, and announcements'). It is not a tautology, but it does not explicitly distinguish itself from sibling getters beyond the resource name.

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

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

No guidance is given on when to use this tool versus alternatives. The description only restates the tool's function with no exclusions, conditions, or comparisons to sibling tools.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'دریافت' (get) implies a read-only operation and the described content is a report, which signals safety. However, it does not explicitly state that no data is modified, whether permissions or authentication are needed, or how the period is determined beyond what the parameter schema already says. For a simple get tool, this is adequate but not rich.

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

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

The description is two short sentences: the first states the main purpose, the second lists the report contents. It is concise, front-loaded, and contains no filler or redundant text.

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

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

For a read-only report tool with an output schema and fully documented optional parameters, the core semantics are covered. The main missing piece is usage guidance relative to the daily report and dashboard siblings. It is adequate but not fully complete for an agent deciding between related report tools.

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

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

Schema description coverage is 100%: both parameters have meaningful descriptions, including the default behavior for period_id ('در صورت خالی بودن، دوره جاری لود می‌شود'). The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'دریافت گزارش سرجمع کارکرد ماهانه پرسنل' (get the monthly summary report of personnel performance). It enumerates the included metrics (کل حضور، کارکرد خالص، مازاد حضور، کسرحضور، اضافه‌کار، مرخصی‌ها و مأموریت‌ها), making it clear this is the monthly aggregate report and differentiating it from kasra_get_daily_report.

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

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

The description provides no guidance on when to use this tool versus kasra_get_daily_report, kasra_get_dashboard_summary, or kasra_export_daily_report_excel. No conditions, exclusions, or alternatives are mentioned. The only period-related hint ('اگر خالی باشد دوره جاری لود می‌شود') lives in the schema, not the description.

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

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

The description uses the read-oriented verb 'Get' and says 'all groups,' which implies a non-mutating list operation, but with no annotations it does not explicitly confirm no side effects, permissions, or rate limits. This is acceptable for a simple read tool but leaves the safety profile implicit.

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

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

The description is short and front-loaded with the main action, and the bilingual duplication is not excessive. It is efficient, though the English sentence could be seen as a near-repeat of the Persian one.

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

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

For a simple list-retrieval tool with an output schema, the description is minimally adequate, but it omits usage context and the role of the 'reason' parameter. Since no annotations exist, these gaps make it less than fully complete.

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

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

The input schema contains one optional 'reason' parameter with 0% schema description coverage, and the description never mentions it. The parameter's meaning and whether it affects results are left entirely to the agent, so the description adds no value here.

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

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

The description states a specific verb and resource: 'Get all personnel groups and attendance policy groups,' including examples like overtime and shift permissions. It is clear, though it does not explicitly contrast with sibling tools such as kasra_get_system_shifts, so it stops short of full differentiation.

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

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

There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites or context. An agent must infer applicability solely 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.

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

No annotations are provided, so the description must carry the behavioral burden. It clearly indicates a read-style profile retrieval and lists the returned fields, which adds useful context. However, it does not disclose whether authentication is required, whether the call is strictly read-only, or any side effects beyond the obvious 'get' semantics.

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

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

The description is short, front-loaded with the core action, and easy to scan. The bilingual Persian/English repetition is somewhat redundant, but it is not bloated and every substantive point appears early.

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

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

For a simple getter with an output schema, the description is mostly sufficient: it names the target resource and the expected data categories. However, it leaves the optional 'reason' parameter unexplained and provides no guidance on when this tool should be preferred over sibling tools, so the context is not fully complete.

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

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

The only parameter, 'reason', has 0% schema description coverage and is entirely absent from the tool description. With no explanation in either the schema or the description, an agent cannot determine what value to pass, why it exists, or what effect it has on the request.

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

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

The description states a specific verb and resource: "Get current user profile" / "دریافت اطلاعات پروفایل کاربر جاری", and enumerates the contents (name, personnel ID, department, role, recent login history). This is clearly distinct from the sibling report/list tools such as kasra_get_daily_report or kasra_get_messages.

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

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

The description gives no explicit guidance about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or sibling routing. The only implied usage is derived from the tool name and the phrase 'current user profile'.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool analyzes punches and returns structured gap data, and implies it's a read-only analysis. However, it doesn't mention edge cases like overlapping shifts, missing punches, or how shift boundaries are handled. The description is honest but not deeply transparent about behavioral details.

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

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

The description is reasonably concise, with a Persian version followed by an English version. It front-loads the core purpose and includes the output structure. The bilingual repetition is slightly redundant but not harmful. Every sentence earns its place.

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

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

The tool has an output schema, so return values are documented. The description explains the purpose, the output structure, and the use case (hourly leave). It doesn't mention pagination or limits, but for a gap-analysis tool with 5 optional parameters, the description is largely complete.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds context about the output structure but doesn't add meaning beyond the schema for parameters. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: analyzing daily punches to find gaps where the employee was out during their shift, and identifies the output (date, gapStart, gapEnd, duration). It also includes a Persian version that adds context about identifying hours needing hourly leave. This distinguishes it from sibling tools like kasra_get_work_periods or kasra_get_daily_report.

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

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

The description explains the tool is suitable for identifying hours that need hourly leave submission, which gives clear context for when to use it. It doesn't explicitly exclude alternatives or name sibling tools, but the purpose is specific enough that an agent can infer when to choose it over other kasra_get_* tools.

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

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

Annotations are absent, so the description carries the full behavioral burden. It does disclose what the call returns (the submitted-request list plus approval/rejection status), adding context beyond the tool name, but it does not address read-only semantics, permissions, pagination, or limits.

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

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

A single compact Persian sentence with the core purpose front-loaded and no filler words. It could be structured to separate usage from behavior, but the size is appropriate for a simple list tool.

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

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

With an output schema present and all three parameters documented in the schema, the description need not explain return values. It covers the purpose and scope but misses usage guidance and behavioral disclosure, which matter more here because no annotations are provided.

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

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

Schema description coverage is 100%, so the baseline is 3. The 'بازه زمانی' (time period) clause loosely maps to start_date/end_date but adds no format or filtering semantics beyond what the schema already documents, and the 'reason' parameter is not addressed at all.

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

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

The description states a specific verb and resource: 'دریافت لیست درخواست‌های ثبت‌شده (مجوزها، مرخصی‌ها، مأموریت‌ها)' — retrieve the list of submitted requests (permits, leaves, missions) — and adds the approval/rejection-status detail. This clearly differentiates it from sibling get_* tools like kasra_get_daily_report or kasra_get_cartable_items, none of which cover submitted requests.

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

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

No guidance is given on when to use this tool versus alternatives; no sibling names or exclusion conditions are mentioned. The only usage hint is the date-range clause 'در بازه زمانی', which implies a filtering scope but does not help an agent choose between this and the many other kasra_get_* tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions a 'get' action, implying read-only behavior, but does not disclose authentication requirements, side effects, or the purpose of the optional 'reason' parameter. Minimal behavioral context beyond the obvious.

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

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

The description is brief and to the point, with no filler. Both Persian and English versions say the same thing efficiently, and the resource type is front-loaded. Every sentence contributes value.

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

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

Although an output schema exists and the purpose is clear, the description omits any explanation of the only parameter, 'reason', and provides no usage guidance or behavioral caveats. For a simple tool this is incomplete, as an agent cannot fully determine how to call it correctly without guessing.

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

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

The input schema has one parameter, 'reason', with no description, and the schema description coverage is 0%. The tool description does not mention this parameter at all, leaving the agent to guess whether or how to fill it. No compensation for the missing schema documentation.

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

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

The description clearly states a specific verb (get/دریافت) and a specific resource (all work shifts defined in Kasra system), with examples of shift types. This distinguishes it from sibling tools that retrieve other data like profiles, reports, or credit types.

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

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

The description implies usage when an agent needs the list of system-defined shifts, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Since there is no close sibling doing the same job, the implied context is acceptable but not fully explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It signals a read operation via 'get' and scopes the response to menus/subsystems, but it does not explicitly state read-only guarantees, authentication needs, or side-effect behavior beyond the verb.

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

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

The description is two short sentences (Persian and English) with no extraneous content. The bilingual repetition is mildly redundant, but overall it is compact and readable.

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

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

The tool is simple, has an output schema, and requires no parameters, so the core call is invocable without risk. However, the unexplained 'reason' parameter and lack of usage/context guidance leave a real but minor gap.

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

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

The input schema contains a single optional 'reason' parameter with no schema description, and the description never mentions it. With 0% schema description coverage and no prose compensation, an agent has no information about what value to supply or why.

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

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

The description uses a specific verb ('Get') and a clear resource ('complete menu structure and subsystems available to the user'), so the tool's subject is identifiable. It does not explicitly distinguish this from sibling tools like kasra_get_desktop_shortcuts, but the menu/subsystem object is clear enough.

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

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

No guidance is given about when to use this tool versus siblings, nor about prerequisites such as authentication or user context. The only usage signal is implied by the description itself: fetch the current user's menu structure.

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

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

There are no annotations, so the description carries the full burden. The verb 'Get' implies a read-only operation, which is clear. However, it does not disclose potential side effects, required permissions, or any behavioral nuances such as pagination or filtering. The description is adequate but minimal for behavioral transparency.

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

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

The description is concise, with two sentences (Persian and English) conveying the same core message. It is front-loaded with the main purpose. The repetition is slight but not excessive, and there is no fluff. It could be slightly tightened by removing the duplicate translation, but it remains efficient.

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

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

The description is complete enough for the main purpose, and an output schema exists so return values need not be explained. However, it omits any explanation of the optional 'reason' parameter, which is a significant gap for correct invocation. For a simple getter, this is adequate but not fully complete.

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

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

The schema has one optional parameter 'reason' with 0% description coverage. The tool description does not mention this parameter at all, providing no meaning beyond the raw schema. Since schema coverage is low, the description must compensate, and it fails to do so, leaving the agent without any guidance on how or why to use 'reason'.

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

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

The description clearly states a specific verb and resource: 'Get all available attendance and financial work periods with their IDs and titles.' This distinguishes it from report or shift tools, though it does not explicitly reference siblings. It is a clear purpose statement, but 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.

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, or exclusion criteria. It merely states what the tool does, leaving the agent to infer usage context. No alternatives are named.

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

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

No annotations are provided, so the description carries the full behavioral burden. It indicates a mutation (submitting a new request) but does not disclose side effects, validation behavior, whether submission is irrevocable, or whether the request enters an approval workflow.

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

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

The description is a single focused sentence that front-loads the action and scopes the request types. It contains no filler or redundant restatement of the tool name.

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

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

The description is enough for basic tool selection and the schema covers parameters, but for a mutating submit action with no annotations it omits workflow context such as prerequisites, side effects, or when hourly time fields are mandatory. The vague 'و ...' ending also leaves the supported types slightly open-ended.

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

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

Schema description coverage is 100%, and the schema itself provides detailed parameter semantics including formats, examples, conditional requirements, and valid credit type IDs. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description states a specific action—ثبت درخواست مجوز جدید (submit a new permission/credit request)—and enumerates the supported types: hourly/daily leave, mission, overtime, remote work. The action verb and 'new' clearly set it apart in action from deletion or retrieval tools, though it does not explicitly name any sibling alternative.

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

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

Usage is implied by the listed request types: an agent can infer it should be used to submit leave, mission, overtime, or remote-work requests. However, there is no explicit guidance about when to use this tool instead of kasra_get_credit_types, kasra_get_submitted_requests, or kasra_delete_credit_request.

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