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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real context beyond them: the blocked module families and a pointer to docs/site-map/api.md for the authoritative endpoint list. It stops short of describing error or rate-limit behavior, so not a 5.

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

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

Three tightly-packed sentences: capability, then scope constraints, then the reference pointer. Front-loaded and every clause carries information.

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

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

For an open-ended passthrough tool with no output schema, the definition covers what it can reach, what is blocked, and where the full contract lives. The absence of any return-shape guidance is inherent to a generic proxy, so the gap is minor.

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 endpoint 'module.method' format and the payload JSON body example are already documented in the schema. The description only adds a pointer to external docs rather than semantics of its own, so the baseline 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?

States a specific verb+resource ('Call any read-only Mizito endpoint directly') and carves out its niche as the escape hatch for data the other 30+ siblings do not cover. An agent can immediately tell this apart from the specific domain tools.

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

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

Gives both sides of the routing decision: use it for data other tools do not cover, and it names the permitted method shapes (get*/search*/history/info/view-style, monitor.* reports). It also states explicit exclusions (account, session, billing, admin-repair modules blocked), which is a genuine 'when not to use' signal.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context that the annotations cannot: results are expressed in Tehran time and include daily hour totals. It still omits paging behavior, page-size limits, and what happens when the offset exceeds available records.

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 sentence with the resource name front-loaded, followed immediately by the returned content and time basis. The parenthetical Persian term earns its place as a query alias. Nothing is padded, though the sentence is dense enough that a second short clause on scope would still read cleanly.

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

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

With four optional parameters, no output schema, and annotations covering safety, the description compensates for the missing output schema by describing the return shape (sessions with start/end, daily hour totals) and the timezone. The remaining gap is that no return-shape detail is given for the manual branch, which differs structurally (paged clock-in/out records).

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 days, kind, offset, and user_id are already documented at the field level, making 3 the baseline. The description adds only the Tehran-time framing and the 'daily totals in hours' output note, which are not parameter-specific, so it does not meaningfully extend the schema.

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

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

The description names a specific resource ('Working-time history (حضور و غیاب)') and states what the output contains: sessions with start/end plus daily totals in hours. That is clearly more than a restatement of the title, but it never distinguishes this tool from neighboring history/dashboard tools such as mizito_get_history or mizito_dashboard, so an agent must infer the boundary.

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 explicit when-to-use guidance, no statement of when to prefer this over mizito_attendance / mizito_get_history, and no mention of prerequisites beyond what the schema already says about admin/monitoring access for user_id. The online-vs-manual distinction lives entirely in the schema's kind description, not in the tool 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds genuine behavioral detail beyond them: placement is by reminder time, deadline-only tasks are absent, and repeating tasks and time-less tasks are returned in separate buckets. This is exactly the kind of return-shape context an agent needs. It stops short of describing pagination or output format, so not a 5.

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?

Four short sentences, purpose front-loaded, and each one carries distinct information (scope, placement rule, exclusions, duplicate-avoidance). No filler or repetition of the tool name. Slightly dense but 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?

With no output schema, the description correctly compensates by describing what is and is not returned (deadline-only tasks excluded; repeating and time-less tasks separated). Annotations cover the safety profile and the schema covers all four parameters, so an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100% and every parameter (by, year, month, project_id) is documented in the schema itself, including the reminder-vs-deadline enum semantics and Jalali defaults. The description's remark about reminder-time placement echoes the `by` default without adding syntax or format detail. Baseline 3 is appropriate when 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 names a specific verb+resource pair ('Tasks on the Mizito calendar') and bounds it to one Jalali month, so the agent knows exactly what is retrieved. It clarifies the calendar's organizing principle (tasks placed by reminder time) which separates it semantically from mizito_list_tasks or mizito_get_gantt. It does not name those siblings explicitly, so it falls short of a 5.

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

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

'Check it before adding events to avoid duplicates' gives a concrete precondition for calling the tool. The note that a task with only a deadline is not on the calendar implicitly tells the agent when this view is the wrong one. However, it never names an alternative tool (e.g. list_tasks or get_gantt) for those excluded cases, so there is context but no explicit routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond them by spelling out the counter categories returned, which matters given there is no output schema; it omits auth/permission needs and whether counts are scoped to the caller.

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

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

Two sentences, no filler, with the core identity (per-workspace counters) front-loaded and the enumerated scope immediately after. Every clause 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?

With no parameters and no output schema, the description does the necessary work by describing what the payload contains (the counter categories) and the framing of the result. It is nearly complete; only the per-workspace grouping mechanics/return shape are left implicit.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify or compensate for.

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

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

The description names a specific resource (per-workspace counters) and enumerates exactly what is counted: unread letters, unread chats, today's/overdue tasks and meetings. This clearly separates it from list/get siblings, though it does not explicitly contrast with the similarly aggregate-sounding mizito_reports.

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?

"Good for a quick 'what needs my attention' overview across workspaces" gives a concrete use context. It stops short of naming when-not-to-use it or pointing at an alternative sibling (e.g. mizito_reports or mizito_calendar), so it is clear-but-not-exhaustive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful payload context (what fields come back, including mute state and open tasks), but says nothing about access constraints, visibility scope, or behavior when the conversation is inaccessible.

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

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

One front-loaded sentence that leads with the resource and then lists the returned facets, with no filler. The parenthetical type enumeration is dense but earns its place by pre-answering what values to expect.

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 output schema, the description must describe the return shape, and it does so concretely (title, type, members with admins, mute state, linked project, open tasks). For a one-parameter read-only tool this is close to sufficient, though it omits any note on visibility limits or how much member/task data is returned.

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 single parameter is fully documented, including its provenance from mizito_list_conversations and mizito_get_project. The description adds nothing beyond the schema, 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?

States a specific resource and enumerates the returned facets: title, type (with the enum of conversation kinds), members/admins, mute state, linked project, and open tasks. It clearly reads as a single-object fetch rather than the list sibling, though it never names mizito_list_conversations explicitly.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The only routing hint ('conversation_id comes from mizito_list_conversations / mizito_get_project') lives in the schema, not the description, so the prose itself carries no usage context.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is partly covered. The description adds genuinely new behavioral context beyond that: the link is public ("Anyone with the link can download that file") and should only be shared with the user, which is a meaningful security disclosure the annotations do not convey.

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

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

Two short sentences with no waste; the core purpose (a download link to give the user) is front-loaded, followed by the sharing caution. Tightly written, though it could more explicitly name the sibling alternatives.

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, two-parameter tool with full schema coverage, no output schema, and annotations covering the safety profile, the description is nearly complete. It states the produced artifact and the key sharing constraint, omitting only edge cases or failure behavior.

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

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

Schema description coverage is 100%, so both parameters (file_id and source) are already documented in the schema. The description adds no format or syntax detail for either parameter, so the baseline 3 applies – 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 states a specific outcome: a direct download link on Mizito's CDN for an attached file, which tells an agent what it produces. It is clear enough to distinguish the general purpose, but it never explicitly contrasts with siblings like mizito_read_file or mizito_view_image, leaving the agent to infer that this returns a link rather than file content.

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?

"to give to the user" implies the use context (surfacing a link to a user), and the sharing caveat constrains behavior. However there is no explicit statement of when to use this versus alternatives, nor any prerequisite or exclusion, 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.

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the significant behavioral gate (Gantt-enabled projects only) and hints at the returned structure, but says nothing about pagination, size limits, or failure modes for a potentially large project chart.

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?

Roughly four lines of dense content with parenthetical Persian glosses (گانت, فاز) that interrupt sentence flow. It is front-loaded and largely earns its place, but the bilingual asides and the trailing eligibility clause make it slightly bulky for a read-only call.

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

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

For a single-param read tool with no output schema, the description is close to sufficient: it conveys both the shape of the return and the precondition for success. The omission of behavior when Gantt is disabled and of result-size guidance keeps it short of 5.

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%; the project_id field already documents its origin ('from mizito_list_projects'). The description adds no parameter detail, but with a single fully documented required param the baseline of 4 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?

States a specific verb+resource (retrieve the project's Gantt chart) and enumerates what the response contains: phases in order, task start/finish dates, progress, assignees, dependencies. It does not name a sibling it is distinct from (e.g., mizito_get_project or mizito_list_tasks), so an agent must infer the boundary, keeping it below 5.

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

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

Gives an explicit eligibility condition: 'Advanced projects with Gantt enabled only.' That tells the agent when the call is valid and warns of an empty/failed result otherwise. It does not point to a fallback tool when Gantt is disabled, so a 5 is not warranted.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the tool returns change details ('who changed what, and when'), but does not disclose pagination, ordering, permissions, or other behavioral traits.

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

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

The description is a single front-loaded sentence with no redundant or wasted language. It immediately states the resource and the returned information.

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

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

For a simple two-parameter read tool with full schema coverage and annotations, the description adequately conveys what the tool returns. It does not explain pagination or ordering, but those gaps are minor given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already fully documents 'kind' and 'item_id.' The description only implies that the item can be a task or project, which mirrors the enum, and adds no extra syntax or constraints.

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

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

The description states a specific resource (change history) and scope (task or project), and clarifies the returned content with 'who changed what, and when.' It is clear but does not explicitly distinguish itself from other history siblings like mizito_support_history or mizito_attendance_history.

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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The intended use is only implied by the resource 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?

The readOnlyHint/openWorldHint annotations already establish the safe read profile, and the description adds real content the annotations don't cover: the returned ordering (first letter, then replies and referrals in order) and the returned fields. It does not mention rate limits, auth requirements, or pagination, which limits it below a 5.

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

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

A single front-loaded sentence that leads with the core action ('Every letter of a thread with full text') and then enumerates the return payload. Dense but every clause carries information; only the mixed-language parenthesis slightly interrupts flow.

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 output schema, the description takes on the job of describing return content and does so thoroughly, including the file_id-to-mizito_read_file link. Given only two simple parameters and read-only annotations, an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so both thread_id and with_seen_details are already documented in the schema (including where thread_id comes from). The description adds no syntax or format guidance beyond that, 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 names a specific verb+resource (read a letter thread) and enumerates exactly what comes back: first letter, replies, referrals (پاراف), sender, recipients, dates, files, labels, linked conversations. It is easy to distinguish from mizito_list_letters, though it never explicitly frames itself as the 'single thread vs. list' counterpart.

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

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

Usage is implied rather than stated: an agent can infer you call this after obtaining a thread id, and it hints at follow-up via mizito_read_file for file_id. There is no explicit when-to-use/when-not statement or named alternative (e.g. mizito_list_letters for browsing).

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine domain behavior beyond that: Mizito only permits editing/deleting before the other party has seen the message, and it discloses the return payload (receipts plus the message itself). That is useful non-obvious context.

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

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

Compact and front-loaded: the primary payload (who has seen the message and when) leads, with the edit/delete rule and message body following. No padding, though the trailing 'Also returns the message itself' is mildly redundant with the opening clause.

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?

No output schema exists, so the description must describe returns, and it does so adequately: read receipts, edit/delete eligibility, and the message. The read-only/open-world annotations carry the safety profile. Only minor gaps remain, such as whether timestamps are absolute or relative.

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 both parameters (message_id, conversation_id) are already fully documented with provenance. The description adds no additional syntax or format detail for the parameters, so the baseline 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?

States a specific verb and resource: retrieving info about a specific message – read receipts (who has seen it and when), edit/delete eligibility, and the message body. This clearly separates it from mizito_get_messages (bulk listing) and mizito_search_messages. It does not explicitly name those siblings as alternatives, which keeps it just below a 5.

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

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

Usage is implied rather than stated – an agent can infer this is the tool for per-message read receipts, but there is no explicit when-to-use/when-not guidance or named alternative. The schema descriptions point to mizito_get_messages/mizito_search_messages only as id sources, not as routing advice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is partly covered. The description still adds real value beyond that by disclosing a non-obvious side-effect policy ('Reading does not mark anything as seen') and by listing the heterogeneous content types that come back, including file_id handoff to mizito_read_file.

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

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

Three tight sentences, front-loaded with what is returned, followed by the side-effect note and then the paging advice. The dense field enumeration is justified because no output schema exists. Minor density cost from stacking paging hints in the parenthetical.

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 output schema, the description correctly compensates by enumerating the returned payload shape and cross-referencing mizito_read_file for file_id. Pagination and the absence of read receipts are covered. Remaining gap is the lack of routing guidance relative to mizito_search_messages and mizito_get_message_info.

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 count, offset, from_date and conversation_id are already documented in detail (including the next_offset/newer_offset interplay and Jalali date formats). The description echoes the offset/from_date paging model but adds no syntax or format detail beyond the schema, 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?

States a specific verb+resource ('Messages of one conversation') and enumerates exactly what is returned (sender, text, files, tasks, polls, meeting minutes, replies), which is far more than a restatement of the name. It does not explicitly distinguish itself from the sibling mizito_search_messages, so it falls short of the top band.

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?

Gives clear operational guidance for the two retrieval modes: page backwards with next_offset, or jump to a date with from_date. It also states the non-obvious fact that reading marks nothing as seen, which shapes when it is safe to call. It stops short of naming alternatives or exclusions (e.g., vs mizito_search_messages).

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 cover readOnlyHint and openWorldHint. The description adds content shape but nothing about behavior: no auth requirements, no rate limits, no indication of what happens with missing message_id, and no mention of the with_history effect beyond restating the schema field. For a read tool with annotations already declaring safety, this is under-explained.

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

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

Two compact sentences with no filler. The content list is front-loaded and the advanced-minutes note follows. Minor issue: the phrase 'For advanced minutes also the state...' is grammatically incomplete but still parseable.

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 3-parameter read tool with no output schema and full schema coverage, the description gives a reasonable sense of returned content, which partially compensates for the missing output schema. It remains incomplete on when to choose this tool over message-oriented siblings and on the required media-type precondition.

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%, so the schema already documents all three parameters including the message_id media types and the conversation_id source. The description adds no parameter meaning beyond what the schema provides, so the baseline 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 enumerates what the minutes contain (subject, date, place, members, text, follow-up tasks, files), which tells the agent the resource is meeting minutes. However, it never states a verb like 'retrieve' or 'fetch', and it does not differentiate this from siblings such as mizito_get_message_info or mizito_get_messages. The purpose is inferable but not crisply defined.

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

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

No guidance on when to use this versus mizito_get_message_info, mizito_get_messages, or mizito_read_file. The description mentions normal vs advanced minutes but does not state when the caller would encounter either or what action to take.

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

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

Annotations already flag readOnlyHint=true and openWorldHint=true, so safety and externalization are covered. The description adds genuinely non-obvious behavioral context on top: visibility gating of per-voter results, plan-dependent availability of the printable report, and the ended flag. It stops short of stating what happens when no poll exists or whether an error is raised.

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

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

A single front-loaded sentence enumerating the return contents, with no filler. It is dense and slightly awkward to parse as one list, but every clause corresponds to real information the caller needs.

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

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

The description covers the return shape well, which matters because no output schema exists. However, it omits error cases (non-poll message, missing poll, permission denial) and any pagination or size expectations, so an agent cannot fully predict failure behavior.

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

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

Schema description coverage is 100%, so the schema already documents both required IDs and their provenance, which is the baseline 3. The description adds nothing about parameter semantics beyond what the schema provides.

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

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

The description enumerates the exact return payload (questions, options, counts, percentages, per-voter responses, own votes, ended status, printable report), so the agent knows precisely what resource is retrieved. The verb is implied by the tool name rather than stated, and no sibling tool covers poll retrieval to distinguish from.

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 parameter descriptions rather than stated: the schema points the agent to mizito_get_messages or mizito_search_messages for the message_id, which is a useful routing hint, but the description itself says nothing about when to call this vs alternatives or any preconditions.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds useful scope context: this is a single-call aggregate that pulls together boards, members, labels, conversation, and statistics, which tells the agent to expect a large, multi-section payload rather than a thin record. It does not disclose pagination, potential size limits, or authorization scope beyond the annotation baseline, so a 3 is appropriate.

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

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

It is a single long sentence that front-loads the aggregate nature of the tool and then packs many returned fields into one clause. It is dense but not wasteful; however, the catalog-style enumeration of every returned sub-object makes it harder to scan than a shorter, better-structured statement would be.

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 one required parameter, full schema coverage, no output schema, and read-only annotations, the description gives the agent a complete enough picture: it explains that this is a comprehensive read of a single project and even indicates intent (verify changes). It could be more complete by noting sibling relationships or expected response size, but nothing essential to a correct invocation 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 coverage is 100% and the single parameter project_id is documented in-schema as 'Project id from mizito_list_projects.' The description adds no format or sourcing detail beyond what the schema already provides, 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 states a specific verb and resource ('Everything about one project') and enumerates the substantive contents returned: owner, members, kanban boards with task counts, labels, conversation, archive state, and statistics. That is a sharp contrast to mizito_list_projects, which returns a collection rather than a full detail view. It stops short of 5 because it never explicitly names the listing sibling it complements.

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

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

It provides one usage cue, 'Use it to verify changes,' which implies a post-mutation verification workflow. However, it does not say when to prefer it over mizito_list_projects, mizito_dashboard, or mizito_workspace_info, nor does it state any precondition such as needing a valid project id. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral detail beyond the annotations — that sections the project or plan lacks are omitted from the response, i.e. the result is partial rather than fixed-shape. It does not discuss permissions, rate limits, or size/volume of the returned catalogue.

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

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

A single front-loaded sentence that leads with the scope and then lists contents; the bilingual glosses (پارامترهای سفارشی, گردش‌کار) and the omission caveat all carry information. It is dense but nothing is obviously padding.

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

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

With no output schema, the description compensates by enumerating what the payload contains and warning that absent sections are dropped. Combined with readOnly/openWorld annotations and a fully documented single parameter, an agent has enough to call it correctly; only permission/scope prerequisites are unaddressed.

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?

Only one parameter exists and schema description coverage is 100%; the schema already explains project_id and points to mizito_list_projects as the source. The description adds nothing about the parameter, so the baseline 3 for schema-covered parameters is correct.

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

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

The description names a specific resource bundle ('everything automated in an advanced project') and enumerates the returned sections: automation rules/buttons, custom task fields, workflows, request forms, task templates, and the rule condition/action catalogue. This is far more specific than a tautology and lets an agent distinguish it from siblings like mizito_get_project or mizito_list_request_forms, though it never states an explicit verb or contrasts itself with those neighbours.

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 when-to-use guidance, no prerequisites (e.g. that the project must be an advanced project with automation enabled), and no reference to an alternative tool. The only usage-adjacent statement is the output caveat about omitted sections, which is not selection guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-derivable behavioral detail: dates are returned in Jalali format, checklist entries carry item ids, and attachments carry file_ids usable by other tools. It omits error/not-found behavior, but the bar is lower with annotations present.

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

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

A single front-loaded sentence that opens with the core purpose and then enumerates contents; every clause carries information and nothing is padded.

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?

There is no output schema, so the description must carry the return contract — and it does, listing every material field including formats (Jalali dates) and cross-tool id references. An agent can call this correctly and know what to expect back.

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?

Only one parameter, task_id, and schema description coverage is 100% — the schema already states it is the `_id`/`id` from mizito_list_tasks, mizito_calendar or mizito_get_project. The description adds nothing about the parameter itself, 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?

States a specific verb (get) plus resource (one task) and enumerates the exact payload: description, assignees, approvers, project/board, dates, repeat rule, checklist, labels, progress, files. That is far more specific than a tautology, though it never explicitly contrasts with the adjacent mizito_get_task_extras or mizito_get_task_comments, so sibling disambiguation is left implicit.

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 explicit 'use this when / use X instead' guidance. It does provide useful chaining context — checklist item ids feed mizito_check_task_item and file_id feeds mizito_read_file — which implies follow-up usage, but the agent must infer when this tool beats get_task_extras or list_tasks.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'oldest first' ordering guarantee and the response contents (author, date, replies, mentions, attached files), which is useful context but not rich behavioral disclosure such as result 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 tight sentence with the resource front-loaded and no filler. It packs ordering and field info without waste, though the sentence is dense enough that it borders on relying on the reader to parse its clauses.

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

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

For a single-parameter read-only getter with no output schema, the description carries the return-value burden well by enumerating author, date, replies, mentions, and attached files plus ordering. The main gap is any mention of result size or pagination for long comment threads.

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 task_id is already documented in the schema, including where to obtain it. The description adds no syntax, format, or constraint details beyond what the schema provides, so the baseline 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?

States a specific verb and resource ('Comments / progress reports on a task') and enriches it with ordering and content details. It does not, however, distinguish this from siblings like mizito_get_task_extras or mizito_get_messages, so it falls short of a 5.

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

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

The description gives no when-to-use guidance and never names an alternative or exclusion. The purpose implies the context but the definition leaves selection between comment-fetching siblings entirely to inference.

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

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

Annotations already cover the read-only/open-world safety profile, so the description's added value is the behavioral note that 'Advanced-project parts are omitted when the project does not use them' — a conditional-omission disclosure the agent can't get from structured fields. The content list further describes what a read returns.

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

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

Two sentences, front-loaded with the payload description and closing with the conditional-omission caveat; dense but every clause carries content. No filler or redundancy.

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

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

For a read-only tool with no output schema, the description carries the return-value burden and does so by listing the content categories and the conditional omission rule. It omits only return formatting/pagination details, which are minor here.

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

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

With a single parameter and 100% schema description coverage, the schema already documents task_id and its provenance. The description adds no syntax, format, or edge-case detail beyond it, so the baseline 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?

States a specific verb and resource ('Extra information about a task') and enumerates the concrete content types returned (creator/views, Gantt placement, dependencies, automation buttons, workflow step, custom field history). This lets an agent distinguish it from mizito_get_task and other task siblings, though the 'extras' framing leaves the boundary slightly implicit.

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 never states when to call this tool versus mizito_get_task or other siblings, and gives no prerequisites or exclusions. It names mizito_run_task_automation only as a downstream action for automation buttons, not as a selection alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: result ordering (newest activity first) and the fact that each conversation carries unread counts, message counts, and pinned status. It omits pagination/limit-follow behavior for a list tool, which keeps it from a 5.

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

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

Two sentences, no filler, and the core scope (what is listed, in what order, with what fields) is front-loaded before the routing hint. Every clause 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?

With no output schema, the description usefully compensates by naming the returned fields (unread and message counts, pinned flag) and the sort order. It stops short of describing list size/pagination semantics implied by the limit parameter, but for a 3-param read-only list tool it is close to 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 kind (with its enum meanings), limit, and unread_only are fully documented in the schema. The description adds nothing param-specific beyond that, so the baseline 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?

States a specific verb+resource ('chat conversations of the workspace') plus scope details (newest activity first, unread/message counts, pinned flag). It is clearly distinct from siblings like mizito_get_messages and mizito_get_conversation, which take ids rather than enumerate.

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

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

Explicitly routes the agent downstream: 'Use the ids with mizito_get_messages, mizito_send_message and the other chat tools,' which establishes this as the entry point for chat flows. It does not say when to prefer mizito_search_messages or mizito_get_conversation over this list, so no explicit alternatives/exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content context (returns ids and colors), but says nothing about ordering, counts, or whether labels are workspace-scoped across the enumerated entity types.

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

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

A single front-loaded sentence with no filler, and the return content is stated early. The phrasing 'of one kind' is slightly terse but efficient overall.

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

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

For a zero-required-param list tool with a fully documented enum and no output schema, describing the returned fields (ids and colors) and the entity scope is nearly sufficient. Only ordering/pagination behavior is left unaddressed.

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% and the single enum parameter is fully documented in the schema itself, including the parenthetical mapping of 'inbox' to letters. The description merely restates the same kind list, so it adds no meaning beyond the schema — the baseline 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 states a specific resource (labels for one kind) and even discloses what is returned — ids and colors — plus the entity types they attach to. It is clearly distinguishable from siblings like mizito_list_tasks or mizito_list_notes, though it never uses an explicit retrieval verb, relying on the name for that.

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 mention of 'for tagging tasks, letters, notes...' implies the use case, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative among the many sibling list tools. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: result ordering and the implicit mode switch that changing filters causes. It does not cover pagination or result limits, which keeps it short of a 5.

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

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

Three tight sentences, front-loaded with the resource and ordering, then the behavioral rule, then the sibling routing. No filler; every clause carries information.

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

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

For an 11-parameter read-only tool with full schema coverage and no output schema, the description supplies the critical missing context (mode switching) and cross-links to the thread tools. Only pagination/return expectations are unaddressed, which is minor.

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 every parameter is already documented in the schema. The description only adds the meta-rule that any filter triggers cross-box search mode; it does not add per-parameter meaning beyond the schema. Baseline 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?

States the resource (letters/نامه‌ها/کارتابل) and the ordering (newest first), and clarifies the two operating modes (box listing vs cross-box search). It distinguishes itself from the letter-thread tools it points to, though it doesn't differentiate from other list/search siblings such as mizito_search_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?

Gives the key selection rule: no filters = list a box, any filter = search across boxes. It also routes to mizito_get_letter_thread / mizito_reply_letter / mizito_manage_letter for thread work. No explicit when-not-to-use or comparison against other list tools, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context beyond the annotations - the privacy guarantee that 'Nobody else sees them' - and enumerates returned fields. It stops short of disclosing ordering, pagination, or what an empty note set looks like.

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

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

Two short sentences, front-loaded with the resource and followed by the privacy scope; nothing is padded. The parenthetical Persian name duplicates the title field slightly, which is the only minor 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 read-only list tool with one well-documented optional parameter and annotations covering safety, the description gives enough to call it correctly: what it lists, what each item contains, and who can see it. Missing pagination/sort behavior is a minor gap given the absence of an output schema.

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

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

There is a single optional parameter (archived) with 100% schema description coverage, so the schema already explains its meaning. The description adds no filtering or default information beyond what the schema provides, 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 states a specific resource - the caller's personal notes - and enumerates the fields each note carries (title, text, color, checklist, labels, pin state), which clearly separates it from siblings like mizito_list_labels or mizito_list_letters. It is clear about what is returned but never explicitly contrasts itself with an alternative note-listing tool.

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

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

There is no statement of when to use this tool versus alternatives, no mention of the archived/active distinction as a usage decision, and no prerequisites or exclusions. The agent must infer usage entirely from the name and the word 'personal'.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the safety profile is known. The description adds real behavioral value beyond that: results are ordered newest first, files come from both conversation and task attachments, and each entry carries its attachment origin. Pagination behavior via offset is left to the schema.

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

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

A single dense sentence that front-loads what is listed and its scope, then covers ordering and the file_id hand-off. Nothing is wasted, though the compressed parenthetical phrasing makes it slightly harder to parse at a glance.

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

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

There is no output schema, but the description compensates by naming the key returned fields (file_id, attachment location) and the ordering, which is what an agent needs to chain into mizito_read_file. Only pagination limits and total-count behavior are unstated.

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 offset, file_name, and project_id are all documented in the schema itself. The description adds only the indirect note that project_id chains from mizito_list_projects via the schema, so the baseline 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?

States a specific verb+resource (list files of a project) with a precise scope: files attached in the project's conversation AND its tasks. It also distinguishes itself from the read-side siblings by naming mizito_read_file and mizito_get_file_link as the consumers of the returned file_id.

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?

Clearly frames the context (files attached anywhere in a project) and points to the follow-up tools that need the returned file_id, which implicitly tells the agent when this tool is the right starting point. It does not, however, explicitly say when not to use it versus siblings like mizito_list_projects or mizito_list_tasks.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely non-obvious behavior — that projects lacking a project conversation still exist and hold tasks yet are hidden from the web app's Projects tab. That is real value beyond the structured fields, though the typed flag values are not fully explained.

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

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

Two compact sentences, front-loaded with what is returned and followed by the edge case. There is minor awkwardness in the line-broken flag mention, but no wasted prose.

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

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

For a zero-parameter, read-only list tool with no output schema, the description supplies the relevant return fields (ids, colors, members) and the key semantic caveat about hidden projects, so an agent can interpret results correctly.

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

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

There are zero parameters, so the baseline of 4 applies; nothing needs param documentation and the description correctly focuses on returned fields instead.

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

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

States the specific resource (projects) and scope (active workspace) plus the fields returned (ids, colors, members), which separates it from mizito_get_project. It never names the sibling explicitly, so the differentiation is implied rather than stated.

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 a nuance in the results (projects without a conversation and why the web app hides them) but gives no explicit when-to-use guidance and never contrasts this with mizito_get_project or mizito_list_project_files. Usage is only inferable from the name and field list.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context beyond that: submissions become tracked tasks in the form's project, and template_id mode returns field metadata (param_id, title, type, required). It does not discuss pagination or return shape for the plain-list mode.

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

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

Three compact sentences, front-loaded with the resource and its dual behavior; nothing is padded. The parenthetical Persian gloss duplicates the title, a minor redundancy, and the third sentence packs two ideas together.

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 one optional parameter, full schema coverage, and no output schema, the description covers both modes and the downstream effect of submissions well enough for correct invocation. Only the plain-list return format is left unstated, which is a minor omission.

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 explains template_id and its purpose, making the baseline 3. The description adds some value by enumerating the field attributes returned in template_id mode, but it does not add syntax or constraints beyond that.

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?

Names a specific resource (request forms) and clarifies the two modes: a plain list of forms you can submit, and a template_id mode that reveals that form's fields. The examples (leave, purchase) and the note that submissions become tracked tasks make the resource concrete. It does not explicitly differentiate itself from sibling mizito_list_templates, which is the only real gap.

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?

States the purpose of the optional template_id argument and names the follow-on tool (mizito_submit_request_form), giving an agent a clear workflow: inspect fields here, submit there. No explicit when-not guidance or comparison to sibling listing tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds the returned-field set and the _id/task_id convention, which is real value, but says nothing about paging behavior, result volume, or what an empty list means.

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

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

Two compact sentences, front-loaded with what is returned and followed by the actionable chaining tip. No filler; slightly terse rather than wasteful.

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 output schema, listing the returned fields is the right compensating move, and the read-only profile is covered by annotations. Missing only paging/termination guidance for the offset parameter, which an agent would otherwise have to infer.

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% — scope's four enum values, offset paging, and the project_id requirement are all documented in the schema itself. The description adds no format or interaction detail beyond that, so the baseline 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?

States the resource (tasks/وظایف) and enumerates the returned fields — ids, titles, assignees, project, board, dates, progress — which is genuinely informative given there is no output schema. The verb 'list' is only implicit in the name, and it does not contrast itself against siblings like mizito_get_task or mizito_calendar.

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

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

The only guidance is a chaining convention: use a task's `_id` as task_id in every other task tool. That is useful, but it never says when to pick this tool over mizito_get_task or mizito_calendar, nor does it explain which scope to choose; usage is only implied via the schema enum.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine domain context beyond that: task templates live on advanced projects, minute/poll templates on the workspace, and the returned template_id feeds the create tools. It omits return shape/pagination, but with annotations present the bar is lower.

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

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

Two sentences, zero filler, with the scope statement front-loaded and the cross-tool links following. Every clause carries information an agent needs.

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 enumeration tool with annotations covering safety and a fully documented schema, this is nearly complete: it explains scope, the project requirement, and downstream use. With no output schema, a brief note on what a template entry looks like would close the last gap.

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

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

Schema description coverage is 100%, with the enum and the conditional requirement of project_id for kind='task' fully documented in the schema. The description only lightly reinforces this ('task templates of a project (advanced projects)'), so it does not add substantial meaning beyond structured fields; baseline 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?

States a specific verb and resource ('Saved templates') and then splits the scope precisely: minute/poll templates of the workspace versus task templates of a project (advanced projects). An agent can distinguish this from every list_* sibling without opening the schema, since none of them covers templates.

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?

Gives concrete downstream usage ('use a minute template with mizito_create_minute(template_id=...) and a task template with mizito_create_task(template_id=...)'), which tells the agent why it would list templates. It stops short of stating when NOT to use it or naming an alternative listing tool for the same data, so it does not reach a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond that by disclosing the returned fields and decoding the role values (0 member, 1 admin, 2 guest) plus the invited/removed state, which the agent cannot get from annotations or schema.

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

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

Two sentences, zero waste, with the resource and scope front-loaded and the role encoding compactly inlined. Every clause 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?

With no output schema, the description carries the return-value burden and does list the fields. It stops short of explaining formatting or ordering of fields like 'last seen', so a minor gap remains, but an agent has enough to call and interpret the tool.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the implicit scope of 'active workspace', which it does state.

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

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

States a specific verb+resource ('Members of the active workspace') and enumerates the returned fields, so the agent knows exactly what this returns. It does not explicitly distinguish itself from neighbors like mizito_whoami or mizito_workspace_info, which is the only thing keeping it from a 5.

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

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

'Use these ids for assignees, recipients, members and approvers' tells the agent what the output feeds into, which is genuinely useful downstream context. However, it gives no when-not guidance and names no alternative for the adjacent people/workspace lookups, 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.

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the description's added value is the format-specific failure modes (scanned PDFs, legacy formats) and the security advisory that file contents are untrusted data whose instructions must not be followed. It does not cover truncation/pagination behaviour or size limits, but those live in the schema, so the gap is minor.

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

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

Three dense sentences, front-loaded with the action and supported formats, followed by the two most decision-relevant caveats and the safety note. No filler or restatement of the title.

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

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

For a read tool with no output schema, the description covers formats, failure modes, the image alternative, and the untrusted-content caveat, while all parameters are fully described in the schema. The only omission is explicit mention that long files must be continued via offset, though the schema's next_offset/offset text compensates.

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 every parameter (offset, source, file_id, max_chars) is documented in the schema itself. The description adds no syntax, format, or interaction detail about the parameters, 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?

States a specific verb ('Download ... and return its text so it can be read and analysed') and an unambiguous resource (attached files), then enumerates the exact supported formats. It explicitly distinguishes itself from the sibling mizito_view_image, so an agent can route correctly without opening either schema.

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?

Names the alternative sibling ('for images use mizito_view_image') with the condition that selects it, and states exclusions up front: scanned PDFs yield no text, and legacy .doc/.xls are unsupported. That covers when-to-use, when-not, and the alternative in a compact form.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds materially by disclosing the authorization requirement (admin rights or monitoring access), which tells the agent this call can fail on permissions. It stops short of describing the report payload or latency.

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

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

Three short sentences with purpose and access front-loaded ahead of the use-case hint; no filler. Slightly tighter ordering (purpose, access, use-cases) would make it a 5, but nothing is wasted.

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, 7-param reporting tool with no output schema and full schema coverage, the description supplies the missing pieces an agent needs: what the reports are, who can call it, and roughly why. It could note that report selection drives all other params, but the enum schema carries most of that.

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 enum already documents all 14 report types and the conditional role of user_id, project_id, project_label_id, from/to dates and search. The description adds no parameter meaning of its own, so baseline 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?

States a specific resource (management reports from the monitoring section) and its domain (workload, delays, activity), which lets an agent place it as the reporting aggregator among siblings. It does not explicitly contrast itself with the nearest siblings (e.g. mizito_dashboard), 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?

Gives concrete context ('useful for analysing workload, delays and activity') and the access prerequisite ('needs workspace admin rights, or monitoring access to advanced projects'). It doesn't name when-not-to-use or point at alternative tools, but the contextual signal is clear.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description only needs to add context — and it does: result ordering (newest first), that each hit carries its owning conversation, and the Arabic ي/ك vs Persian ی/ک normalization quirk that would otherwise cause silent misses. It does not mention paging limits or result caps, but the offset parameter documents paging in the schema.

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

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

Two front-loaded sentences: the core behavior first, then a clearly flagged 'Tip' for the one non-obvious gotcha. Both sentences earn their place, though the parenthetical scope aside is slightly redundant with the schema enum.

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?

There is no output schema, so the description must convey what comes back — it names the hit's conversation and ordering, which is the essential shape. Paging is delegated to the offset parameter. Minor gaps remain (no result-count limits, no indication of match/highlight format), keeping it short of 5.

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%, so query, scope and offset are already fully documented with defaults and enum meanings; baseline 3 applies. The description restates the chat-vs-customers scope split and the Persian/English query hint without adding format or syntax detail beyond the schema.

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

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

States a specific verb and resource ('Full-text search across every chat message'), names both scopes (workspace chats vs customer conversations), and adds result ordering ('newest first') plus the payload ('with the conversation each hit belongs to'). This is clearly distinguishable from siblings like mizito_get_messages, mizito_list_conversations and mizito_get_message_info, which are retrieval-by-id or listing tools rather than search.

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

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

Usage is implied by the verb 'search' and the scope/tip, but the description never states when to prefer this over mizito_get_messages, mizito_list_conversations or mizito_api_read, nor any exclusions. The 'Tip' addresses how to phrase the query (Arabic vs Persian glyphs), not which tool to choose, so routing guidance remains implicit.

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

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

Annotations already supply readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content-level context (past Q&A and an unread count), but says nothing about ordering, recency limits, or whether results are paginated.

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

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

A single front-loaded sentence with no filler. The parenthetical is slightly wordy but earns its place as a disambiguator against workspace conversation tools.

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

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

For a no-argument, read-only history tool with no output schema, the description covers what the tool fetches and its scope. Only minor gaps remain (result ordering/volume), which are not essential to correct invocation.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to explain. No syntax or format detail is needed or missing.

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

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

States a specific resource (the user's support conversation with Mizito) and what is returned (past Q&A plus unread answer count). The parenthetical '(the company behind Mizito, not your colleagues)' preemptively distinguishes it from sibling conversation/message tools like mizito_list_conversations and mizito_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 scope clarification implies when this tool applies (support-thread Q&A rather than workspace chats), but there is no explicit when-to-use/when-not or named alternative. The differentiation from siblings is inferable rather than stated as 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the result is something 'you can look at it directly,' implying image content is returned rather than a link or text, which is useful but thin beyond what annotations provide.

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

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

A single front-loaded sentence with the verb and resource leading and the clarifying parenthetical examples placed efficiently. No filler or redundancy.

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

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

For a simple annotated read tool with a fully documented schema and no output schema, the description supplies enough to call it correctly. It stops short of naming the file-access alternatives, which is the only notable gap for an agent choosing among many file-related siblings.

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 both parameters (file_id and source) are already fully documented, including the fallback syntax for source. The description adds no parameter-level detail, so the baseline 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?

States a specific verb (show) and resource (attached image), reinforced with concrete examples (photo, scanned letter, screenshot) that tell the agent this is a visual rendering tool. It does not, however, distinguish itself from close siblings like mizito_read_file or mizito_get_file_link, leaving the agent to infer the split.

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 'attached image' and by the source parameter's context strings (conversation/task/letter), but there is no explicit when-to-use or when-not-to-use guidance and no mention of the alternative file-access siblings. The agent must infer that this loads image content rather than text.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read nature is covered. The description adds valuable context beyond that: it enumerates the concrete fields returned (role, creation rights, plan type) and explains the plan gating semantics for advanced features, which is genuinely useful behavioral context.

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

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

The description is front-loaded with the core purpose and then the plan-tier caveat, which is relevant but a bit dense. It is slightly long and mixes return-value enumeration with usage guidance, but every sentence carries useful information.

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

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

With no output schema and no annotations covering return content, the description does the heavy lifting by naming the returned fields and plan semantics. It is almost complete for an identity tool, though it could note whether the plan info is authoritative or cached.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly implies a parameterless call (call it first for your own id) and adds no misleading parameter expectations.

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 it returns the logged-in user, the active workspace, and switchable workspaces with role and plan info. This is a specific identity/context retrieval resource and is reasonably distinguishable from siblings like mizito_workspace_info or mizito_list_users, though it does not explicitly name those alternatives to sharpen the boundary.

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

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

It gives clear when-to-use guidance: call it first to get your own user id (e.g., to self-assign a task) or to check admin/guest status. It stops short of naming when not to use it or which sibling to prefer for other identity/workspace queries.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds authorization-dependent behavior that annotations cannot express: plan details (limits, invoices) are visible only to workspace admins, so non-admin callers get partial results. It also points to the sibling needed to act on pending invitations.

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

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

Two sentences, front-loaded with the primary returned fields before the admin-visibility caveat and the cross-tool pointer. Dense but every clause conveys content an agent can act on; no filler.

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

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

With no output schema, the description must carry the return-value burden, and it does so by enumerating the fields returned (name, plan status, permissions, invitations, unread badges). The admin gating is disclosed, so an agent can interpret a sparse response correctly.

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

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

The tool takes zero parameters, so the schema carries no semantics and the baseline of 4 applies. No parameter-level detail is needed or missing.

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

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

The description names the resource (workspace) and enumerates the specific payload: name, plan status (trial, remaining days, storage), permissions, pending invitations, unread badges. That is far more informative than a tautology, though it is framed as a content list rather than an explicit verb, and it never contrasts itself with the closest sibling mizito_whoami.

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

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

It implies usage by describing what the caller will receive and routes a follow-up action to mizito_respond_workspace_invitation, but it never states when to call this versus mizito_whoami or mizito_dashboard. The admin-only visibility note is a condition, not a use-case selection rule.

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