Insurance Research Expert by Spot

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description reveals how the answer is constructed: every factual statement is copied from validated evidence and linked to its source. This is significant behavioral context—users know the output is bounded, sourced, and not freely generated—which adds real value over the structured annotations.

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

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

Two sentences with no wasted words: the first states the purpose, the second states the behavioral guarantee. The most important information is front-loaded.

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

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

Given the single obviously named parameter, the presence of an output schema, and annotations covering safety, the description provides all necessary context. It even clarifies sourcing and linking behavior, leaving no critical gap for an agent deciding how to invoke 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?

Schema description coverage is 0%, so the description carries the burden of explaining the single 'question' parameter, and it does not explicitly do so. However, the parameter is self-evident from its name and the tool's 'generate an answer' purpose, and no additional formatting or scope details are strictly needed. The description provides indirect meaning but does not fully compensate for the absent schema description.

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

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

The description uses a specific verb-object pair: 'Generate a bounded answer' from 'retrieved public evidence.' This clearly distinguishes it from sibling tools like search_knowledge (searching), get_page (fetching a page), and compare_providers (comparing) without needing to open those definitions.

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

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

The description clearly communicates the intended use: produce a grounded, evidence-based answer rather than raw search results or page content. It does not explicitly name alternatives or provide when-not-to-use exclusions, but the purpose is contextually distinct enough for an agent to select it appropriately.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds useful behavioral context: it explains the returned content, caveats that this is not proof of coverage or availability, deterministic-rule behavior, and that no customer data or saved submissions are used.

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 dense but appropriately front-loaded: it first states scope and required inputs, then optional parameters, then return behavior and caveats. The long platform list is necessary for scope, though some phrasing is repetitive and could be tightened slightly.

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 carries the burden of explaining return values, and it does: driver requirements, local-rule scope, platform trip-stage cover, unresolved items, source sections, and research dates. It also covers input scope, optional conditional-gap parameters, usage caveats, and determinism, leaving little an agent needs to know before invoking it.

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 only 40%, so the description must carry more semantic weight. It names all ten parameters in context, including vehicle, ownership, commercial-driver status, city, New York licence category, comprehensive/collision, delivery days, and annual delivery kilometres, and explains that these optional inputs identify conditional gaps. It does not explain every enum value, but it meaningfully compensates for the low schema 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?

The description states a specific verb and resource: check source-backed rideshare/delivery insurance requirements across named platforms and jurisdictions. It clearly scopes the tool to insurance checklists, but it does not explicitly differentiate itself from any sibling tool, though the siblings are mostly provider/review/knowledge tools rather than direct alternatives.

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 invocation guidance by requiring an ISO jurisdiction and every platform used, and explains that optional fields identify conditional gaps. However, it does not state when to use this tool versus alternatives, nor does it provide explicit exclusions beyond noting that the result is a checklist rather than proof of 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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: aliases and reversed orderings collapse to one canonical comparison, retired per-coverage URLs redirect to the pair comparison, and the 'need' input runs only a bounded editorial judgment without inventing rankings or purchase recommendations. These are meaningful operational constraints the agent could not infer from structured fields.

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

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

Three sentences, front-loaded with the core operation and then the optional-input semantics; little waste. The final sentence is clause-heavy ('does not invent a ranking or a purchase recommendation') but each clause adds a distinct constraint, so it earns its length.

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 not be described, and annotations cover safety, so the description focuses correctly on behavior and optional-input effects. It is nearly complete; the only omission is failure behavior for an unknown or unpublished provider, which matters for a lookup tool that resolves aliases.

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 0%, so the description must carry the load, and it does for the two optional parameters: 'coverage' gets concrete examples ('cyber', 'D&O', 'workers comp') and an effect (lists each provider's published offering page for that line), while 'need' is described as a bounded editorial judgment. providerA/providerB are covered indirectly via the note that aliases and reversed ordering resolve to the canonical comparison, implying order-insensitivity and alias tolerance. A brief note on what an unresolvable provider name yields would close the remaining gap.

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

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

The description opens with a specific verb and resource ('Retrieve a published, sourced provider comparison') and immediately narrows the scope to a canonical two-provider pair, which cleanly separates it from sibling tools like get_rankings, get_provider_score, and get_provider_reviews. An agent can identify the operation and its bounded nature without opening the 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?

Usage is implied rather than stated: the mention of 'Optional coverage' and 'Optional need' tells the agent what the optional inputs trigger, and the note that per-coverage line comparisons are retired implicitly tells the agent not to look for a separate line-level tool. However, there is no explicit when-to-use/when-not guidance or named alternative among the nine sibling tools.

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

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

Annotations already declare readOnly/openWorld=false/destructive=false, and the description adds genuinely useful behavior: lists are returned complete even when the website collapses them, and industry pages include parent/vertical links. It stops short of noting any caching or rate-limit behavior, but coverage is solid for a read 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?

Front-loaded with the core action and followed by the coverage inventory, which is dense but earns its place. The middle enumeration of path families is long and somewhat run-on, though it is informative rather than 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?

Output schema exists, so return values need not be described, and the description fully covers what is retrievable, which path forms are valid, and which content classes are excluded. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0% and the single `path` param has no schema-level documentation, so the description must carry it. It does: it specifies canonical path or URL and lays out the accepted path grammar (/industries/{slug}/{question}, /best/{line}/{segment}), giving the agent concrete input formats.

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 verb (Retrieve) and resource (published Spot page) and enumerates the concrete path families it serves (/industries, /best, provider profiles, comparisons, reviews, rankings), which clearly separates it from the sibling search_* and ask_* tools. An agent can tell what this returns without opening the 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?

Gives explicit when-not conditions: drafts, customer-specific guides, submissions, and unknown paths are unavailable, which prevents dead-end calls. It does not name a fallback sibling (e.g., use search_knowledge for drafts), so the routing guidance is strong 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 mark the tool as read-only and non-destructive, so the description doesn't need to restate that. It adds valuable behavior beyond the annotations: unpublished or unavailable review records return found:false, and the response includes full Markdown with citations. This helps the agent anticipate absence handling without assuming an error.

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

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

The description is two sentences with no filler. The first sentence front-loads the core action and return contents; the second addresses the not-found case. 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?

For a single-parameter, read-only retrieval tool with an output schema present, the description is complete. It covers what the tool does, what data it returns, how the provider parameter should be interpreted, and the behavior when no published review is available.

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

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

The schema provides only the field name and length constraints, with no description, so the description carries the semantic load. It explicitly states that the single 'provider' parameter accepts a name, alias, or slug, which is essential for correct invocation and is genuinely additive to 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 uses specific verbs ('Resolve', 'retrieve') and a specific resource ('provider reviews'), and enumerates exactly what is returned: review summary, Review Score contributors, original source metrics, qualifications, and full Markdown with citations. This clearly distinguishes it from sibling search tools like search_provider_reviews, which implies a lookup rather than a fuzzy 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?

The description gives clear context for when to use it: when you have a provider name, alias, or slug and need published review details. It does not explicitly name sibling alternatives or state when not to use them, but the 'resolve' language and the provider input make the intended invocation scenario 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 safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false). Beyond that, the description usefully discloses that aliases resolve to a canonical assessment and that an optional need runs a 'bounded editorial judgment over that assessment only' — real behavioral context. It stops short of describing rate limits, caching, or failure modes, so not a full 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 core action before the editorial caveat and the need parameter note. Little wasted text, though the 'not an AM Best rating or a recommendation' clause is a slight detour.

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 read-only annotations cover the safety profile. The description adds aliasing behavior and the semantics of need, leaving only provider-identifier format as an unaddressed detail.

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 0%, so the description must carry parameter meaning. It does explain the effect of the optional need argument and that provider aliases resolve to a canonical record, but it never clarifies accepted provider formats (name, alias, ID, domain) despite minLength/maxLength constraints in the schema. Partial compensation only.

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 (a published reliability assessment and Reliability Score) scoped to 'one provider', which cleanly separates it from the multi-provider siblings search_provider_reliability and compare_providers. An agent can identify the operation without opening the 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?

The description explains what the score is (editorial, not an AM Best rating) but never states when to use this tool versus the sibling search_provider_reliability or compare_providers, nor any prerequisite conditions. No when/when-not guidance is present.

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 readOnly/destructive=false and closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: scores are split by segment, the combined score is an average, partial/unrated assessments retain qualifications, and the 'need' judgment is bounded to published tables only (i.e., it won't synthesize data).

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 sentences, each earning its place, with the core purpose front-loaded before segmentation details and the sibling routing. Some phrasing ('keep their qualifications', 'bounded editorial judgment') is terse to the point of slight ambiguity.

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 structure need not be restated. The description covers the ranking model and one of two parameters; the only real gap for a 2-param read-only tool is the unexplained includeMethodology flag.

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 0%, so the description must carry parameter meaning. It partially does for 'need' ('runs a bounded editorial judgment over the published tables only'), which conveys what the string drives, but 'includeMethodology' is never explained and 'need' gets no format or length guidance.

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 ('Retrieve the current published Reliability Score rankings') and immediately disambiguates scope: Broker vs Carrier & MGA are ranked separately with a combined average. It also names the sibling it is not, so an agent can separate it from search_provider_reliability 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?

Explicitly routes filtered lookups elsewhere ('Use search_provider_reliability for provider, score, and status filters'), which is a clear alternative plus the condition that selects it. It does not state any when-not condition or prerequisite for the rankings view itself, so it falls just short of the top score.

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 safety is covered. The description adds genuinely non-structured context beyond that: retrieval is deterministic lexical (not semantic), which sets expectations on query phrasing and result stability, and research results carry thegeneralaverage.com URLs, which tells the agent what the output domain is.

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 the verb, but the body is a single sprawl of ~18 enumerated content types that could be summarized as 'Spot's published pages and insurance research content'. It also contains a typo ('thegeneralaverage.com') and buries the one distinctive trait (lexical retrieval) mid-sentence.

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 cover safety. For a search tool competing with ask_spot and eight lookup siblings, the missing piece is routing guidance rather than parameter detail; the definition is minimally viable but leaves the agent guessing which search surface to pick.

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 0% for two parameters, so the description must compensate — and it does not. It never explains 'query' syntax (natural language vs keywords, effect of the 2-500 char bound) or 'limit' (default 5, capped at 8), beyond the indirect signal that lexical matching is used.

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 (Search) and a specific resource scope (published Spot pages plus Spot's insurance research corpus), which an agent can recognize as a knowledge-base search. However, it does not differentiate itself from siblings such as get_rankings, get_provider_reviews, search_provider_reliability, or ask_spot — it actually claims to cover reviews, Reliability Scores and rankings that those siblings own, muddying 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?

No when-to-use guidance and no alternative routing. The phrase 'deterministic lexical retrieval' hints that keyword input is expected, but nothing tells the agent when to prefer this over ask_spot (semantic) or the specific sibling lookup tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds useful domain behavior by explaining what rubric='all' actually averages (Broker vs Carrier & MGA scores), but says nothing about result breadth, pagination behavior, or what 'published' excludes.

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 action and filter set front-loaded; no filler. The second sentence's nesting ('the one a provider has') is slightly awkward but still compact and information-dense.

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 described. Given 8 parameters at 0% schema coverage, the description should cover the remaining filters and pagination; it omits limit/offset and the rating enum semantics, leaving an agent to guess at page sizing and the meaning of rated/unrated.

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 0%, so the description carries the burden, and it does explain query, score range, sort targets, and the rubric='all' combined-score rule. It still leaves limit and offset entirely unexplained, does not define the 'rated'/'unrated' values, and calls the rating filter 'status,' a naming mismatch with the actual schema property.

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: 'Search published Reliability Score assessments,' with scoping filters (query, status, score range) and sort options. An agent can tell it is a list/search tool rather than a single-entity fetch, though it does not explicitly name siblings like get_provider_score or search_provider_reviews 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?

Usage is implied by the named filters and the rubric semantics, which helps an agent decide when the combined-score view applies. However, there is no explicit when-to-use/when-not guidance versus get_provider_score (single provider) or search_provider_reviews, leaving selection 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds material behavioral detail: scores equally weight eligible source ratings on a 10-point scale and use an approximate academic conversion for BBB grades. This helps the agent interpret results and is not available from the schema or annotations.

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

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

Three sentences with no fluff: the first front-loads purpose and filters, the second adds scoring methodology, and the third routes to an alternative. Every sentence earns its place.

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

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

The description covers purpose, filters, sort, scoring behavior, and an alternative. It does not mention pagination (offset/limit) or inclusive/exclusive boundary semantics for the score range, but the output schema exists and the input schema provides defaults/max, so an agent can still proceed 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 description coverage is 0%, so the description must compensate. It maps query, Review Score range (minScore/maxScore), rating availability, and sort options (alphabetical/by score). It does not explain limit/offset, but those are standard pagination parameters and the schema already provides defaults and bounds.

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 begins with a specific verb and resource ('Search published provider reviews') and clearly names the filtering dimensions (query, Review Score range, rating availability) and sort options. It also distinguishes itself from the sibling get_provider_reviews by pointing to source-level evidence, so an agent can tell them apart.

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 explicitly says 'Use get_provider_reviews for source-level evidence', giving a clear when-not and an alternative. The main use case is implied by the filter and sort semantics, so the agent knows when to invoke this tool versus the named sibling.

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