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

With no annotations, the description must carry behavioral disclosure, but it only restates the create action. It does not mention idempotency, duplicate-name behavior, or whether creation is irreversible; this is a meaningful transparency gap 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 with no filler; the action and target resource are stated in the fewest words that retain meaning.

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 one-parameter creation tool with no output schema, the description is minimally viable, but an agent still lacks information about success/failure behavior, duplicate handling, or side effects. This is a clear gap without being severe.

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 already documents the single name parameter with 100% coverage, so the baseline is 3. The description adds no additional semantic detail about name format or constraints, but it doesn't need to compensate.

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 (Create) and resource (dataspace, in Locus), clealy distinguishing this tool from list_spaces/delete_space and from docment/scpace tools. An agent can identify the intended operation without needing extra context.

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 implies the tool is for creating a new dataspace, which is the only place such an operation could occur among the siblings, but it does not explicitly state when to use it over alternatives or any exclusions. This is adequate but minimal.

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 only states the action 'Delete', implying destructiveness, but does not disclose permanence, irreversibility, cascading effects, required permissions, or return behavior. This is insufficient for a mutation tool with zero 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 sentence of only eight words that directly states the action and scope. No filler or redundancy, and the key verb 'Delete' 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?

The tool is simple with two documented required parameters and no output schema. The description and schema together are sufficient to make the call, but lack behavioral context such as permanence, error behavior, or side effects that annotations would normally provide. Given the absence of annotations, a bit more context would be better, but the simplicitity keeps it adequate.

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?

Input schema covers 100% of parameters with descriptions ('Name of the dataspace', 'Document ID to delete'). The tool description adds little beyond the schema, merely restating that deletion is by ID and within a dataspace. Baseline of 3 applies due to high 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?

Description states a specific verb 'Delete', resource 'document', identifier 'by its ID', and scope 'Locus dataspace'. This clearly differentiates it from siblings like delete_space, get_document, and list_documents without ambiguity.

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 implies usage when deleting a document from a dataspace, but it does not explicitly mention alternatives such as delete_space or conditions for not using this tool. The resource scope provides clear context, but no explicit decision rules are given.

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 of disclosing destructiveness. It clearly states that the dataspace and all its documents are deleted, which is the key behavioral trait. However, it does not mention irreversibility, permissions, or other side effects.

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

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

The description is a single concise sentence that front-loads the action and main consequence. Every word earns its place with no redundancy or 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 one-parameter destructive tool with no output schema, the description covers the essential behavior: what is affected (dataspace and all documents). It omits minor details like irreversibility or return behavior, but these are not critical for basic selection and invocation.

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

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

The input schema fully describes the only parameter, 'space', as 'Name of the dataspace to delete' with 100% coverage. The description adds no additional meaning, format, or examples beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Delete'), specifies the resource ('a dataspace'), and adds the cascading scope ('all its documents'). This clearly distinguishes it from sibling delete_document and from list_spaces/create_space.

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 'and all its documents' implies this tool is for deleting an entire dataspace rather than a single document, but there is no explicit when-to-use or when-not-to-use guidance. The distinction from delete_document is only implicit.

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

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

Since no annotations are provided, the description must carry the behavioral burden. It clearly conveys a read-only retrieval operation returning full text, which is appropriate. It does not disclose behavior on missing IDs, error handling, or any access restrictions, but for a simple get-by-id tool this is a moderate gap.

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

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

One succinct sentence that front-loads the action, resource, and key discriminator. Every word earns its place and there is no redundant or generic 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 tool with only two required, fully documented parameters and no output schema, the description is largely sufficient. However, it does not mention what happens when the document is not found, how to discover IDs, or any edge cases, and there are no annotations to fill that 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 baseline 3 applies. Both parameters are documented: space names the dataspace and doc_id identifies the document. The description adds no parameter-specific detail beyond what the schema already provides.

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

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

The description states a specific verb ('Retrieve'), a concrete resource ('the full text of a document'), and the lookup mechanism ('by its ID'), all scoped to a Locus dataspace. This clearly distinguishes it from sibling tools like list_documents or search, which serve different discovery purposes.

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 implies the right use case: call this when you already have a document ID and need the full text. However, it does not explicitly say to use list_documents or search when the ID is unknown, nor does it name alternatives or exclusions.

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

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

With no annotations, the description carries full burden of behavioral disclosure. 'Get' clearly signals a non-mutating read operation, and specifying the two pieces of returned data (Ollama URL and embedding model) provides concrete transparency. It lacks details on errors or response format, but for a zero-parameter getter this is sufficient.

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 entire description is one efficient sentence that front-loads the action and resource, then provides the key details in a parenthetical. There is zero wasted wording.

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, parameterless getter with no output schema, the description covers the essential information an agent needs: what it does and what data it returns. It omits the response shape or types, but these are inferable from the named fields ('Ollama URL' implies a string, 'embedding model' implies a string).

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

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

The tool has zero parameters, so the schema is trivial and no parameter documentation is needed. The description correctly focuses on the resource rather than parameters, matching the baseline of 4 for tools with no params.

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 ('Get') with a clear resource ('current Locus settings') and immediately names the exact fields returned ('Ollama URL and embedding model'). This distinguishes it from siblings like update_settings and health_check without needing to open any schemas.

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 implies the obvious use case: call this when you need the current settings, as opposed to update_settings when you want to change them. However, it does not explicitly state when not to use it or name alternatives, leaving the guidance implicit rather than explicit.

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 or output schema, the description must disclose behavior on its own. It states that the tool checks health and reachability, but does not explain how success/failure is signaled (e.g., return value, exception, HTTP status), nor whether any side effects or permissions are involved. For a simple health check, the core behavior is clear, but the response contract is left unspecified.

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

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

The description is a single, well-structured sentence that front-loads the verb and carries no filler. Every word contributes to understanding the tool's purpose.

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 trivial no-parameter health check, this description is largely sufficient. However, the absence of any information about the return format or failure behavior could leave an agent uncertain about how to interpret the result, which is a minor gap for tool-selection and invocation.

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

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

The tool has zero parameters, so there is no parameter semantics to convey. The baseline of 4 for a zero-parameter tool applies; the description correctly focuses on the operation rather than non-existent arguments.

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 ('Check') with a clear resource ('the Locus service') and desired outcome ('healthy and reachable'). It unambiguously identifies the tool's purpose and is naturally distinct from sibling tools, which all perform CRUD operations on spaces, documents, settings, or 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 clearly implies a health-check/diagnostic use case, but it does not explicitly state when to use this tool versus the sibling tools. There are no exclusions or guidance on prerequisites, though the distinct nature of the operation makes the intended context evident.

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 of disclosing behavior. It usefully reveals that file_path reads locally without loading content into context, but it does not disclose potential side effects, permissions, overwrite behavior, or response format. This is partial but not complete transparency.

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

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

The description is a single tight sentence that front-loads the core action, then gives the most important invocation guidance. No words are wasted and the parenthetical rationale is efficient.

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

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

For a moderate-complexity tool with four parameters and no output schema, the description provides the essential decision rule between file_path and text and explains why file_path is preferred. It could mention what happens after ingestion (e.g., return value, errors), but the current content is sufficient for an agent to call the tool correctly.

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

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

The schema already covers all four parameters at 100% coverage, so baseline is 3. The description adds meaningful value by establishing that file_path and text are mutually exclusive alternatives, and by explaining the practical advantage of file_path. This goes beyond simply restating parameter names.

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

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

The description clearly states the tool's purpose with a specific verb ('Ingest'), target resource ('a document into a Locus dataspace'), and the two accepted input modes. This distinguishes it from sibling tools like list_documents, get_document, and delete_document.

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

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

It provides clear guidance on how to invoke the tool: prefer file_path over text, and explains why using file_path avoids loading content into context. It does not explicitly name sibling tools or state when not to use them, but the purpose is unambiguous enough to make tool selection straightforward.

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 must carry the full burden of behavioral disclosure. It only says 'List all documents' without explaining pagination, whether full document contents or metadata are returned, or any rate limits or read-only guarantees. This is a significant gap for a list 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?

The description is a single, front-loaded sentence with no redundancy or filler. Every word contributes to the core purpose, making it highly concise and well-structured.

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 1-parameter list operation, the description is minimally viable but incomplete. It does not mention expected return shape, pagination, or whether the output includes document metadata or content. Given there is no output schema and no annotations, more behavioral context would be needed for full completeness.

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 already provides 100% coverage for the only parameter, 'space', describing it as 'Name of the dataspace'. The description adds the phrase 'Locus dataspace', which reinforces the parameter's meaning but does not provide additional syntactic or semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a clear verb and resource: 'List all documents in a Locus dataspace.' It is more specific than simple 'List documents' by including the scope 'all' and the dataspace context. However, it does not explicitly differentiate from sibling tools like get_document or search, which would have earned a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives such as search or get_document. There is no mention of use cases, exclusions, or conditions that would make this tool the appropriate choice. The intended usage is only implied by the verb 'List'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List all dataspaces in Locus' and adds no details about return format, read-only guarantees, ordering, pagination, or potential errors.

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

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

The description is a single, front-loaded sentence with no wasted words. Every element contributes to understanding what the tool does.

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 trivial zero-parameter list operation, the description is nearly complete: it names the resource and scope. The only missing contextual detail is the structure of the returned list, which would be useful since there is no output schema.

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

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

The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The description correctly omits parameter information.

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 ('List') plus a specific resource ('dataspaces in Locus'), making its purpose immediately clear. It is naturally distinguished from sibling tools like list_documents, create_space, and delete_space.

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 description: use this when you need to list all dataspaces. However, there is no explicit guidance about when not to use it or how it compares to sibling tools, though the zero-parameter nature makes the decision straightforward.

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 must carry the full burden of behavioral disclosure. It communicates that search is semantic rather than exact-match and that the input is natural language, but it does not state whether the operation is read-only, what the result entries look like, ranking behavior, pagination, errors, or limits beyond the schema. This is a meaningful gap for a tool with no annotation metadata.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation, resource, and search modality, making it easy for an agent to parse quickly.

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 provides good parameter coverage and defaults, which compensates for many operational details. However, with no annotations and no output schema, the definition leaves result shape and selection behavior underspecified. It is minimally viable for invoking the tool correctly, but not rich enough to fully self-contain the expected behavior.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description adds minor contextual meaning by tying 'space' to a Locus dataspace and 'query' to natural language, but it does not add substantive parameter semantics beyond what the schema provides.

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

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

The description states a specific verb ('search'), a specific resource ('documents in a Locus dataspace'), and the search method ('semantic search using natural language'). This clearly distinguishes it from list_documents, which would be a structural listing rather than a semantic query.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor is an alternative like list_documents named. However, the phrase 'semantic search using natural language' implies when it should be preferred over ordinary listing tools, so usage guidance is present but only by 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?

With no annotations provided, the description carries full behavioral disclosure burden. It discloses the locking constraint, adding useful transparency beyond just 'update'. But it does not mention what happens when settings are locked, whether changes persist, or any side effects, leaving some behavioral ambiguity 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?

Description is exactly two sentences: first states the action and object, second adds the key constraint. No fluff, no redundancy, and 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?

For a simple tool with two optional parameters and no output schema, the description covers the essential behavior and the main gateway condition. Missing are return/error details and a bit more context around side effects, but these are not critical for a basic settings update call.

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 both parameters already have clear descriptions in the schema (ollama_url with uri format, embed_model with an example). The tool description merely restates the two parameters without adding defaults, constraints, or syntax details, so it adds no semantic value 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 states a specific action ('Update'), the resource ('Locus settings'), and the exact scope ('Ollama URL and/or embedding model'). This clearly distinguishes it from the sibling get_settings and other document/space tools.

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

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

The description provides an important precondition ('Only works if settings are not locked via environment variables'), which implicitly tells the agent when not to call it. However, it does not explicitly state 'use this to modify settings' or mention alternatives like get_settings, so usage guidance is mostly implied rather than fully spelled out.

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