Liminal

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

With no annotations, the description carries the full burden, and it does disclose the output shape (verbatim answer-bearing passages rather than a summary) and a size threshold that hints at cost. It says nothing about side effects, whether the input is stored or transmitted, or permission/rate characteristics, which matters for a tool that ingests user text.

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 the core behavior, then the routing rule, then the pointer for extra detail. Zero filler; every clause carries information.

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

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

For a 4-required-param tool with no output schema, the description covers what goes in, what comes back, and when to prefer it, plus a pointer to get_capabilities for deeper detail. It remains thin on side-effect/privacy behavior and on the two undocumented parameters, so it is strong but not exhaustive.

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 50%: context and llm_model are documented in the schema, while task and text are bare. The description partly compensates by explaining that 'text' may be a URL or long text and that 'task' is the question being asked, but it leaves both underspecified (no size/format guidance) and the 'More args' pointer is cryptic.

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 concrete verb+resource action (pass text plus task, get answer-bearing passages verbatim) rather than a restatement of the name. It implicitly distinguishes itself from the sibling 'read' by describing itself as the replacement for opening long content, so an agent can route correctly without opening either schema.

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

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

Gives an explicit, quantified use condition ('anything over 8,000 chars') and names the alternative it substitutes for (opening/reading), which is a real routing rule. It does not spell out the inverse case in words or say what to do for shorter inputs, so it stops just short of the 5 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?

With no annotations, the description carries the full behavioral burden and does little. It implies a safe read (schema retrieval) but never states read-only status, whether any side effects occur, or why context/llm_model are required for something that looks like pure introspection. No rate-limit, auth, or return-format disclosure.

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 efficient sentence with the core behavior front-loaded and zero filler. It is telegraphic to the point that a verb is missing from the first clause, which slightly hurts parseability, but every element 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?

No output schema exists, so the description should ideally characterize the return; it does say it returns a full argument schema or the tool list, which is the essential point. However it omits the required analytics params (context, llm_model), any note that these are mandatory, and the result's shape/format, leaving gaps for a 3-param 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 coverage is 67%, above the 50% baseline, and the two highest-value params (context, llm_model) are already well documented in the schema. The description usefully explains the one undocumented param: tool=<name> returns that tool's schema. This maps the tool parameter's semantics but adds little else, so a baseline 3 is appropriate.

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

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

The description states a specific verb+resource: it enumerates every Liminal tool and, given tool=<name>, returns that tool's full argument schema. That is a concrete, distinguishable capability (a discovery/introspection tool) rather than a restatement of the name. It stops short of differentiating itself from siblings like read or solve, and the first clause is a verbless fragment, but the purpose is clear.

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, no prerequisites, and no mention of when not to use it. The agent must infer that this is a self-discovery call to be made before invoking an unknown sibling tool. No explicit usage context is provided.

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, yet it says nothing about persistence lifetime, auth requirements, rate limits, or what 'save' or 'resume' actually mutate or return. 'Save or continue work across sessions' hints at persistence but discloses no concrete behavioral traits.

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

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

Very terse and front-loaded, with the core purpose first and action-arg groups following. The telegraphic style is efficient, though it borders on cryptic enough to occasionally cost clarity.

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 8-param, multi-action tool with no annotations and no output schema, the description is thin, though it does route the agent to get_capabilities for additional arguments. It leaves return behavior, persistence semantics, and mode selection under-specified.

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 50%, and the description helpfully maps undocumented params to their action (create: task, session_state, evidence, subject; resume: subject or handoff_id), a relationship the flat schema does not convey. It does not add format or syntax detail, but it meaningfully compensates for the coverage 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 states a specific purpose ('Save or continue work across sessions') and enumerates the three action modes (create/resume/list), which lets an agent distinguish them from siblings like focus or solve. It does not, however, differentiate itself relative to the sibling tools by name.

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

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

It implies when each action applies by mapping args to modes (create: ...; resume: subject or handoff_id; list), and points to get_capabilities for more args. But there is no explicit when-to-use/when-not guidance versus alternatives like focus, leaving selection largely 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no read-only confirmation, no pagination or result-size behavior, no return format. 'query filters' is the only behavioral hint, which is far short of what an unannotated tool needs.

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 definition is a single compact, front-loaded fragment pair with no wasted words. It is terse to the point of under-specification, but structurally there is nothing extraneous 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?

With 4 params (two of them unusual required metadata fields), no output schema, and no annotations, the description should explain what is returned and how results are shaped, but it does not. For a tool whose name gives no clue and whose required params are non-obvious, this leaves significant 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 coverage is 50%: the two required params (context, llm_model) are documented in the schema, while kind and query are not. The description partially compensates by enumerating kind values (work|results|sources) and noting that query filters, but 'query filters' is too vague to fully explain the parameter's syntax or matching behavior.

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 noun phrase 'Your saved results and sources' implies retrieval and the 'kind: work|results|sources' fragment hints at the resource scope, but the description never states a verb and does not distinguish this generic 'read' tool from siblings like research, focus, or solve. An agent can guess it retrieves saved artifacts, but the purpose is only loosely pinned down.

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 any alternative tool. The only routing signal is the implied 'kind' selector, which is left for the agent to infer.

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 adds some value by signaling the output is fetched and cited (external network use, citation-bearing results), but it discloses nothing about latency, cost, rate limits, or what happens with the data submitted.

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

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

Two short clauses, purpose front-loaded first, no filler. The trailing "More args" pointer is slightly cryptic, but the overall size is appropriate for the tool's simplicity.

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 and no annotations, and the description omits the cost/latency profile and any description of the 'question' parameter, so it is only minimally complete for a 3-required-param tool that performs external fetches.

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 67%, and the description adds no meaning about any parameter beyond pointing to get_capabilities for more detail. The unnamed 'question' param is undocumented in both schema and description, but the schema covers the other two adequately for a baseline 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?

It names a concrete verb+resource: answering a web research question with fetched, cited findings. That is clear enough for an agent to understand the operation, but it never distinguishes itself from siblings like solve or read, so a 4 rather than 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?

"More args: get_capabilities(tool=...)" does route the agent to a sibling for additional argument details, which is useful. However, it gives no when-to-use / when-not-to-use guidance, no prerequisites, and no comparison to the solve or read tools that might overlap.

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 disclosure burden. It hints at single-call batching ('in one call') but says nothing about cost, latency, side effects, whether the operation is read-only, or what a result looks like — significant gaps for a tool that performs reasoning over a request.

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

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

A single compact sentence with the core purpose front-loaded and the exclusion clause immediately after. Every clause carries information, though the trailing get_capabilities pointer is somewhat abrupt.

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 five parameters, no annotations, and no output schema, the description is thin — it never explains what 'frame' produces or what a caller gets back. It leans on the get_capabilities escape hatch, which is helpful but not a substitute for describing the tool's own behavior.

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

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

Schema coverage is 60%: question and llm_model are well documented in the schema, follow_up_of has a terse description, while context and task_id are undocumented. The description adds only a pointer to get_capabilities for the remaining args rather than explaining any parameter itself.

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

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

States a concrete verb+resource ('frame and answer a non-trivial decision or multi-step request') and scopes it against simple work ('skip simple lookups'). However, it does not differentiate itself from sibling tools like research or focus, which an agent might reasonably confuse for the same multi-step reasoning task.

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 a clear when-not condition ('skip simple lookups') and routes the agent to get_capabilities(tool=...) for additional arguments. It stops short of naming the concrete alternatives (research, focus, read) that would fully resolve selection ambiguity.

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