ABS · AI Business System

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the closed-world, non-mutating profile is largely covered. The description adds that answers are cited, which is genuinely new and useful, but says nothing about behavior when the KB lacks an answer, latency, or limits — appropriate for a 3 given annotation coverage.

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 brief sentences, front-loaded with the action and immediately followed by the grounding and citation contract. 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?

An output schema exists, so return values need not be explained, and the annotations cover safety. What is missing is the operational context an agent needs to choose this over search_knowledge, which is the main completeness gap for this 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%, with both 'question' and the 'lang' enum fully documented in the schema. The description adds no syntax, length, or language-selection 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 a specific verb (ask) and resource (the ABS assistant), plus the grounding scope ('answers only from the ABS knowledge base') and a distinguishing behavior (cites sources). It implicitly separates itself from search_knowledge by being an answering tool rather than a retrieval tool, but it never names or contrasts the 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?

There is no when-to-use guidance and no routing against the obvious alternative, search_knowledge. The agent must infer that this tool is for natural-language questions vs. raw passage retrieval, and nothing tells it when this tool would be a poor choice.

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 only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds genuinely new behavior: immediate return with status 'generating', an asynchronous build taking a minute or two, a specific polling interval, and the fact that the output lands as a user-reviewed draft rather than a finished artifact.

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?

Front-loaded with what the tool produces, then the async/polling mechanics, then the side effects (draft state, credit consumption). Sentences are dense and every one carries new information; nothing is restated from the schema or annotations.

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 async, credit-consuming generation tool, the description covers what an agent needs to act: it returns a code immediately, how long to wait, the polling target and cadence, the terminal status, and that a human submits the result. With an output schema present, it correctly avoids explaining return field shapes.

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 lang, question and start_date are already documented with format, enum and length constraints. The description reinforces that the input should be a single sentence but adds no syntax or constraint detail beyond the schema, 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 opens with a specific verb+resource ('Turn one sentence into an execution plan') and enumerates the plan contents (phases, steps, schedule, forms, sources, coverage gaps), so the agent knows exactly what it produces. It also implicitly separates itself from get_plan by casting that sibling as the polling companion, which is the closest thing to a same-resource sibling.

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 well spelled out: call this once, then poll get_plan roughly every 20 seconds until status is draft, and the result is a draft the user submits in ABS. It does not say when to prefer this over other planning-adjacent siblings like ask or diagnose, so it falls short of the explicit when/when-not/alternatives bar.

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?

Goes well beyond the annotations by disclosing that content is transmitted to an external service and AI model, that it consumes the account's credits, and that payloads are capped at 5 MB. These are non-obvious cost, data-exposure and size constraints that an agent cannot infer from readOnlyHint/destructiveHint.

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, both front-loaded: the capability and its outputs come first, the operational caveats (data egress, credits) second. No filler, no restatement of the name or 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?

With an output schema present, return values need no explanation, and the description covers cost, privacy and size for a 6-parameter tool. The one gap is that all 6 parameters are optional, so the description never says what happens or which mode is chosen if neither a question nor a file is given.

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 baseline is 3, but the description adds real value: accepted file families (spreadsheet, document, shop-floor photo), the required base64 encoding, and the 5 MB ceiling. It doesn't clarify how 'question' and 'content_base64' interact 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 ('Assess a situation') and the shape of the deliverable ('judgement, actions and sources'), plus both accepted input modes. It does not distinguish itself from the sibling tool 'ask', which an agent could easily confuse with this one.

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?

Conveys the trigger context (a question or a file) and adds a confidentiality obligation ('ask the user before sending anything confidential'), which is real usage guidance. However it gives no when-not guidance and never routes the agent to or away from the close sibling 'ask'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's extra value is naming the returned sub-fields, but an output schema exists, so this usefully hints at content shape without telling the agent anything the structured data does not already carry.

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 that front-loads the resource and then lists the payload contents. It is not padded, though as a noun phrase fragment it omits a verb and reads more like a title expansion than a full description.

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

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

For a simple two-parameter read tool with full schema coverage, complete annotations and an output schema, the description is just barely sufficient. The missing piece is routing guidance — when to reach for get_course versus list_courses or get_plan — which no structured field supplies.

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%: course_id is documented as coming from list_courses and lang is documented with its zh/en enum. The description adds nothing about either parameter, which is the expected baseline 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?

States the resource (one course) and enumerates its content — lessons with objective, key points, practice task and knowledge check — so an agent knows this returns a single course's instructional payload. It does not explicitly contrast with get_plan or get_source_page, but the resource noun is specific enough to distinguish it from the list_courses sibling.

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 statement, no prerequisites, and no mention of alternatives such as list_courses (which the course_id schema description implies as a prior step). Usage must be inferred entirely from the name and schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds genuine behavioral value by disclosing the two lifecycle states returned ('progress while generating' versus 'the whole plan in Markdown once ready'), which 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?

A single front-loaded sentence that identifies the resource first and then the return states. It is efficient, though the parenthetical '(status draft)' is cryptic and slightly muddies an otherwise clean line.

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 one-parameter read tool with an output schema, the description covers the essentials: it names the resource, the identifier, and the two return states. Error or not-found behavior is not addressed, but with an output schema present and only one required param, that 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% for the single 'code' parameter, and the schema already tells the agent where the code comes from (create_plan or list_plans). The description's 'by its code' adds no syntax, format, or validation 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?

The description states a specific verb and resource (fetch one plan by its code) and even characterizes the payload at each stage. It implicitly contrasts with list_plans by saying 'One of this account's plans by its code', though it never names a 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?

Usage is only implied: an agent can infer this is for retrieving a single plan once you have a code, versus list_plans for enumeration. There is no explicit when-to-use, when-not-to-use, or prerequisite guidance, so the agent must infer the routing itself.

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 destructiveHint=false, so with the lower bar the description still adds value by disclosing the return medium (an image) and the single-page constraint. It stops short of discussing auth or limits, which is acceptable given the rich annotations.

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

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

Three short sentences, front-loaded with what is returned, followed by input sourcing and a constraint. Every sentence carries weight, though the phrasing is slightly clipped.

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?

An output schema exists, so return format need not be re-explained, and annotations cover the safety profile. The description covers input sourcing, medium, and scope constraint, leaving little an agent needs missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters; the description only reinforces that the pdf name and page come from a card listing. This is the correct baseline 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?

States a specific verb+resource and scope: one page of an original source document returned as an image, framed as 'to check a rule or number.' It is clearly distinguishable from the siblings, though it does not directly name a contrasting 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?

'Use the pdf name and page listed by get_tool_card' supplies a concrete routing precondition, and 'to check a rule or number' gives the motivating context. It adds the 'Single pages only' constraint, but names no explicit when-not or 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only a content inventory, which largely overlaps the output schema; it discloses nothing about payload size, caching, or access requirements. Minimum viable given the annotation coverage.

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. Slightly list-heavy, but every clause names real returned content rather than padding.

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

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

For a two-parameter read tool with an output schema, the description covers what is needed to call it correctly. Its return-value enumeration is somewhat redundant with the output schema, but nothing essential is missing.

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

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

Schema description coverage is 100%: card_id is documented with examples (smed, 5s, psp) and lang carries an enum description. The description adds no 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?

The description identifies the resource precisely ('the full text of one tool card') and enumerates its parts (definition, steps, decision rules, formulas, sources, rule parameters, original pages). It is clear what comes back, though it never states an action verb and never distinguishes itself from siblings like get_source_page or get_course.

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, and no mention of alternatives such as get_source_page, even though that sibling returns 'original pages' that this tool also surfaces. The agent must infer the routing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description contributes one useful behavioral fact beyond that: results are personalized with the calling user's progress. It says nothing about ordering, filtering, or whether the catalogue is paginated, so it is only a modest addition.

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 ten-word sentence with zero filler, and the identifying scope ('this user's progress') is placed where it is read first. It is efficient, though it borders on under-specified rather than tightly informative.

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

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

For a zero-required-parameter read tool with an output schema and full annotation coverage, the description supplies the two things structured data cannot: the resource identity and the personalization of results. Usage routing is the only real gap, and that is already penalized under usage guidelines.

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 'lang' parameter has a fully documented enum, so the schema carries the burden. The description adds no information about language selection or defaults, which is the correct baseline when the schema is self-explanatory.

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

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

The description names a specific resource (the ABS course catalogue) and adds scope detail (it includes this user's progress), which distinguishes it from the sibling get_course that fetches a single course. It is a noun phrase rather than a verb+resource statement, so the 'list all' action is only implied by the name, but the intent is unambiguous.

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

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, and no mention of alternatives such as get_course for a single course or list_plans for plans. The agent must infer usage purely from the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral trait beyond that — results are ordered newest first and scoped to the caller's account — but says nothing about pagination or how to page beyond the limit cap.

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 fragment with zero wasted words, and the scoping constraint is front-loaded. It borders on under-specification rather than being genuinely concise, which keeps it from 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a single-parameter read-only list tool the description is nearly sufficient, with only pagination behavior 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?

Schema description coverage is 100%, with the single 'limit' parameter fully documented including its 1-50 range, so the schema does the heavy lifting. The description adds no additional meaning about the parameter, which is the expected baseline of 3.

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

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

The description identifies the resource (plans) and the exact scope (this account created), plus the sort order, so an agent knows this returns the caller's own plans rather than a global list. It never names the verb 'list' explicitly and does nothing to distinguish itself from the sibling get_plan, so it falls short of full sibling differentiation.

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

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

There is no statement of when to use this tool versus get_plan, list_courses, or search_knowledge, and no prerequisites or exclusions. The agent must infer from the name alone that this is the enumerate-everything variant.

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 the safe read-only, closed-world profile, so the bar is lower. The description adds genuine behavioral value beyond them by disclosing that results are short excerpts with links and the basis of each rule, not full documents — a trait that shapes how the agent should follow up.

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 zero filler; the capability statement is front-loaded and the follow-up routing is appended where it is useful. 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 an output schema present the description needn't detail return values, and it sensibly summarizes the response shape anyway. It is complete for a search tool, though it could note the closed-world scope limitation implied by openWorldHint=false.

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 three parameters (query, lang, limit) are documented in the schema, so the description adds no parameter meaning beyond it. 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 (Search) and resource scope, enumerating the content types it covers (tool cards, terms, forms, courses, guides, rules). It also explicitly distinguishes itself from get_tool_card, which returns full text, so an agent can tell the two apart without opening a 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?

It routes the agent to the sibling get_tool_card when full text is needed, which is clear context-specific guidance. It lacks explicit when-not conditions (e.g. when to prefer ask or diagnose over raw search), so it falls short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description's help. The description adds some value by naming what is revealed (account, site, permissions), which is a side-effect-free introspection trait, but since an output schema exists this is largely redundant and no auth or rate-limit behavior is disclosed.

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

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

A single compact sentence that front-loads the action ('Check the connection') and then enumerates the returned facts. There is no filler and nothing to trim.

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 introspection tool with an output schema already defined, the description is sufficient: it tells the agent what the call returns and implies no arguments are needed. The only shortfall is the absence of any hint about when this is preferable to `diagnose`.

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 of 4 applies. The description correctly implies a no-argument call by framing it as a pure connection check, adding 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?

States a specific action (check the connection) and enumerates what the result reveals: the ABS account, the site, and its permissions. An agent can tell this is an identity/connection-introspection tool. It does not, however, explicitly distinguish itself from the sibling `diagnose` or explain the relationship between the two.

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 phrase 'Check the connection', which suggests calling it to verify identity and connection state before other operations. There is no explicit when-to-use guidance, no statement of prerequisites, and no routing away from siblings like `diagnose` that could also cover connectivity questions.

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