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

With no annotations, the description carries the full burden. It does disclose a meaningful side effect beyond the schema — that bundle assets are written into app-config.json — but says nothing about failure behavior, whether the output directory is overwritten, or required environment/auth state.

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 first and no filler. It is appropriately sized, though it lacks any structural cues for when/when-not usage.

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 parameterized build-and-mutate tool with no annotations and no output schema, the description is minimally adequate: it covers the build and the asset-sync side effect but omits prerequisites, failure semantics, and what the tool returns.

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 all three parameters (projectDir, outputDirName, autoSyncAssets) are already well documented. The description only loosely gestures at autoSyncAssets via 'automatically synchronize bundle assets' and adds no 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: 'Build the Zalo Mini App project', plus a secondary action of synchronizing bundle assets with app-config.json. The purpose is unambiguous, though it does not explicitly distinguish itself from near-neighbors like zmp_validate_project or zmp_sync_config.

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

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

There is no guidance on when to run this versus zmp_validate_project, zmp_sync_config, or zmp_deploy, and no stated prerequisites (e.g., whether a login/token must exist first via zmp_wait_for_login). The agent must infer the workflow position on its own.

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

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

With no annotations at all, the description carries the full burden. It usefully discloses the generated stack, which tells the agent what it gets, but says nothing about filesystem side effects, whether an existing targetDir is overwritten, or any auth/permission needs for a tool that writes a project tree.

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 that front-loads the action and resource, with the distinguishing stack details packed compactly. No filler sentences.

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 mutation tool with no annotations and no output schema, the description explains what is produced but omits overwrite/error behavior and expected return, leaving the agent to infer the post-conditions of scaffolding.

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 all five parameters (including the optional appId and the template enum) are documented in the schema itself. The description adds no parameter-level meaning beyond that, 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 (Scaffold) and resource (new Zalo Mini App project) plus the exact stack produced (React 18, ZAUI, Vite, Dark Mode zero-flicker). This clearly separates it from build/deploy/validate siblings, though it does not name any sibling 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 word "new" implies this is for fresh projects rather than existing ones, giving weak implied guidance. There is no explicit statement of prerequisites, no when-not-to-use, and no routing to alternatives such as zmp_validate_project or zmp_build for already-scaffolded projects.

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

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

With no annotations, the description carries the full burden. It usefully discloses that uploads are chunked, assets are auto-synchronized, and testing quota is tracked. But it never states permission/token requirements or whether a deploy mutates or overwrites remote state, which matters for a write operation.

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

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

A single front-loaded sentence with no filler; the deploy verb and target lead. Slight redundancy in listing multiple process mechanisms instead of using that space for usage guidance.

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

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

Covers the operation's mechanics, but for a no-annotation write tool with six parameters and no output schema it omits auth/token context, failure modes, and when deployment should be avoided. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description adds no per-parameter meaning 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 and resource ('Deploy Zalo Mini App to Zalo Cloud') plus the mechanisms involved. However, it does not distinguish this from the sibling zmp_build, so the agent gets no explicit contrast within the deploy family.

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 when-to-use guidance, no prerequisites (e.g., whether a build must precede deploy or whether a token/login is required), and no named alternatives. The agent must infer the workflow entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Retrieve' implies a read-only operation and it names the source API, but it does not disclose authentication requirements, rate limits, error behavior, or any other operational details.

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

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

A single sentence that is front-loaded with the verb and resource, and contains no wasted words.

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

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

The schema fully documents parameters and no output schema exists, so the description's broad mention of returned data (metadata, quotas, versions) is useful. However, it omits usage context and behavioral details that would fully orient an agent for a read-only retrieval 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level syntax or format details beyond what the schema provides, making 3 the appropriate baseline.

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 ('Retrieve') and resource ('Mini App metadata, quotas, and versions') plus the source API ('Zalo Developer API'). It clearly distinguishes itself from write-oriented siblings like create_app, build, and deploy, though it does not explicitly name them.

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?

Provides no when-to-use guidance, no alternatives, and no prerequisites. An agent must infer that this is for inspecting app information rather than managing login, building, or deploying.

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

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

With no annotations provided, the description carries the full behavioral burden. 'Check' implies a read, but the description never states that it is non-mutating, whether it performs network I/O, whether it can trigger a refresh, or what happens when the token is invalid or expired.

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

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

A single well-formed sentence with the verb and resource front-loaded and no filler. It is appropriately sized, though the brevity comes at the cost of the missing guidance noted in other dimensions.

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

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

There is no output schema, so the description should explain what 'status' actually returns (e.g., logged-in boolean, token validity, expiry). Without that, an agent cannot reliably interpret the result of a status probe or know whether a follow-up login step is needed.

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

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

Schema description coverage is 100%, so both parameters are already documented (projectDir as an absolute path containing .env, token as an optional explicit ZMP_TOKEN). The description only restates 'project directory or token' and adds no precedence rules for when both are supplied.

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 ('Check authentication status with Zalo Mini App Platform'), so the operation is unambiguous. It does not distinguish itself from the closely related zmp_wait_for_login sibling, which an agent would need to tell apart when deciding whether to poll or check once.

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 phrasing 'for a given project directory or token' hints at scope but never says when to call this versus zmp_wait_for_login, zmp_request_login_qr, or zmp_start_oauth_callback. No exclusions, prerequisites, or sequencing guidance are given for a tool sitting in a dense login-flow cluster.

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

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

No annotations exist, so the description carries the full behavioral burden. It implies a new session is created but never says whether an existing session is invalidated, what permissions or Zalo account state are required, how long the QR remains valid, or what happens when polling times out. The one behavioral hint ('wait/poll until scanned') largely duplicates the waitForScan schema field.

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 tight sentences with the core action front-loaded and no padding. The second sentence is slightly redundant with the waitForScan field, keeping it just short of a 5.

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 annotations and no output schema, the description must explain the result, yet it never says what is returned (QR image, URL, session ID) or how to consume it. For a tool whose entire point is producing a scannable artifact, this is a material 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%, so the baseline is 3. The description adds no parameter detail beyond what the schema already documents (appId, projectDir, timeoutSec, waitForScan), and the wait/poll mention only restates waitForScan.

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: 'Request a new developer login session and generate a QR code for Zalo authorization.' This distinguishes it from siblings like zmp_wait_for_login and zmp_get_login_status by naming the QR-generation act, though it does not explicitly name the sibling it is not.

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

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

The clause 'Can optionally wait/poll until scanned' implies a relationship to zmp_wait_for_login, but the description never says when to use this tool versus that one or zmp_start_oauth_callback. Usage is only implied, 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?

With no annotations, the description carries the full burden. It usefully discloses the write target (project local .env file), which is genuine side-effect context, but it omits overwrite semantics, whether the file is created when absent, and whether both values must be supplied together.

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

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

A single well-formed sentence, front-loaded with the action verb and ending with the concrete write target. Every word earns its place with no redundancy.

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

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

For a simple 3-parameter config writer with no output schema, the description covers the core purpose and target, and the schema covers parameters. However, it lacks the when-to-use context and the relationship between optional appId/token that an agent needs to invoke it confidently.

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, establishing a baseline of 3. The description adds modest value by mapping the parameters to the .env keys APP_ID and ZMP_TOKEN, but contributes no format or validation 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?

The description names specific actions (save/update) and concrete resources (APP_ID and ZMP_TOKEN in the project local .env file), so the agent knows exactly what this tool does. It is clear but does not differentiate itself from a sibling like zmp_sync_config, which may also manipulate project config.

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

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

There is no guidance on when to call this versus alternatives such as zmp_sync_config or zmp_create_app, nor any stated prerequisites (e.g. needing a token before build/deploy). Usage must be inferred entirely by the agent.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this binds a local HTTP server on localhost and captures a redirect code/token, but says nothing about whether the call blocks until the callback arrives, what happens on timeout (timeoutSec is only in the schema), or how the captured code is handed off.

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 example URL earns its place by pinning down the callback path shape. It is appropriately sized for a four-parameter tool, though it is too terse to carry the flow context the tool 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 tool with four optional parameters, no annotations, and no output schema, the description explains the mechanism but not the surrounding contract: what is returned or persisted, whether it blocks, and how it chains into zmp_set_token or zmp_wait_for_login. It is minimally sufficient but leaves real gaps.

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

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

Schema description coverage is 100%, so port, zaloAppId, projectDir and timeoutSec are already documented in the schema. The description adds only the illustrative callback URL that happens to match the default port; it does not explain parameter interactions (e.g. that projectDir controls where the token is persisted). 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: 'Start a local HTTP OAuth callback server', with the concrete example URL making the mechanism unambiguous. It is clear what the tool does, but it does not differentiate itself from the closely related auth siblings (zmp_wait_for_login, zmp_request_login_qr, zmp_set_token), so an agent must infer the ordering from context alone.

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

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

The phrase 'to capture redirect code/token' implies a goal but gives no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer this over zmp_wait_for_login or zmp_set_token. An agent in the OAuth flow has no stated signal about where this step belongs.

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

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

No annotations are provided, so the description carries the full burden. It implies a write/mutation by synchronizing assets into config files, but it does not disclose whether existing entries are overwritten or merged, required permissions, or what happens if the target files are missing. Some behavioral context is present (which files are modified), but significant gaps remain for a mutation tool.

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

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

A single, front-loaded sentence that states the action, the assets, the target files, and the benefit. Every clause earns its place with no redundant or vague filler.

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

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

For a simple two-parameter tool with complete schema coverage and no output schema, the description explains what is changed and why. However, with no annotations and no output schema, it omits timing relative to sibling build/validate tools and behavioral details like overwrite semantics, leaving an agent with some uncertainty about invocation context.

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

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

Schema description coverage is 100%, so both parameters (projectDir and outputDirName) are fully documented in the schema. The description adds no parameter-level detail beyond the schema, which is the baseline 3 for high coverage.

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 (Synchronize) and resources (CSS and JS build assets, app-config.json, app.json) and the outcome (prevent "No asset defined" errors). It does not explicitly differentiate itself from siblings like zmp_build or zmp_validate_project, 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?

Provides no when-to-use guidance, no prerequisites, and no alternatives. The only implied usage is the error it prevents, but it does not say when to call it relative to build, validate, or deploy, matching the calibration's 'no guidance' score of 2.

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

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

With no annotations, the description carries the full burden, but it does disclose genuinely useful behavior: the exact validation categories and the 10MB/3MB size thresholds and allowed-extension check. It leaves unclear whether the operation is purely read-only, what it reports on failure, and whether outputDirName affects which artifacts are inspected.

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 with the main action front-loaded and no filler. The enumerated checks are packed but each clause carries specific information relevant to the tool's scope.

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

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

For a two-parameter validation tool with no annotations and no output schema, the description covers what is validated but not what the caller receives (pass/fail, error list) or how failures surface. That is a meaningful gap for a validation tool whose whole value is its report.

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 projectDir and outputDirName are already documented in the schema. The description adds no parameter-level 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?

States a specific verb ("Validate") and resource ("project configuration") and enumerates the concrete checks performed, including numeric limits (10MB/3MB) and app-config.json format. It does not name or distinguish itself from any sibling, but the siblings are mostly auth/build/deploy operations that are not close substitutes.

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

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

There is no guidance on when to run this versus alternatives such as zmp_build or zmp_sync_config, nor any prerequisite or sequencing hint (e.g., run before build or deploy). The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two important traits: the call blocks and polls, and it has a mutation side effect (writing ZMP_TOKEN into .env). What it omits is failure behavior — whether it errors or returns a status when timeoutSec elapses, and whether the token write is idempotent.

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

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

A single front-loaded sentence that names the action, the awaited user gesture, and the resulting side effect with no redundant or filler content.

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

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

There is no output schema or annotation coverage, yet the description adequately conveys what the tool does and its persistence side effect for a simple 3-parameter tool. It is only slightly incomplete in not describing timeout/error outcomes or how the completion is surfaced to the caller.

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 all three parameters (zmpsk, projectDir, timeoutSec) are already documented in the schema, including the default of 60 seconds. The description adds no syntax or format detail beyond 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 and resource — poll/wait for the user's QR scan authorization — and adds the side effect of persisting ZMP_TOKEN to .env. It is clear on its own, but it never differentiates itself from the neighboring zmp_get_login_status or zmp_request_login_qr tools, so the agent must infer the ordering.

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 only implied: the description mentions the QR authorization flow and the zmpsk parameter ties it to zmp_request_login_qr, so an agent can guess it runs after requesting a QR. However, there is no explicit when-to-use statement, no mention of when to prefer zmp_get_login_status (non-blocking poll) instead, and no note on prerequisites such as having an open QR session.

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