ContexteTech

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the shape of the estimate (tokens, per-call/per-pass cost, batch discount, cheapest model, GPU fine-tuning), but says nothing about pricing model currency handling, latency, rate limits, or how the estimate is scoped to a resource.

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

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

A single dense sentence that front-loads the core deliverable ('Estimated cost of a ContexteTech resource ... in euros') before listing what the estimate includes. Slightly telegraphic and comma-heavy, but nothing is wasted.

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-only estimation tool with no output schema, the description usefully enumerates what the estimate contains, which substitutes for the missing return-value documentation. It never explains what a 'code' resolves to or whether any setup is required, which is a minor 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 coverage is 100% for the single 'code' parameter, so the schema already documents it; the description only implies that this code identifies a 'ContexteTech resource'. Baseline 3 applies because the structured field does the heavy lifting and the description adds no format or resolution details beyond it.

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 deliverable (a cost estimate in euros for a ContexteTech resource) and enumerates its components: input/output tokens, cost per call or pass, batch discount, cheapest model, and GPU fine-tuning for datasets. It is a noun-phrase fragment rather than a verb+resource construction, but it is clearly distinguishable from siblings like fetch, search_resources, or fill_prompt.

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 about when to call this versus the alternatives (fetch, load_resource, search), no prerequisites, and no indication of whether it should precede or follow loading a resource. Usage must be inferred entirely from the name and the enumerated output components.

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=true, so the safety profile is covered. The description adds only that the complete (not partial) content is returned; it says nothing about pagination, truncation, auth requirements, or failure behavior for invalid ids.

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: verb, resource, scope, and id provenance in one pass. Nothing is redundant or 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 one-parameter read tool whose annotations already cover the safety profile, this is nearly sufficient: the agent knows what it retrieves and what to pass. The only gap is that with no output schema, nothing describes the shape or size of the 'full content' returned.

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?

With one parameter at 100% schema coverage the baseline is 3, and the description adds real meaning by stating where the id comes from (the return of search) and that a short code is acceptable via the schema. This provenance hint helps the agent supply a valid value rather than just naming the field.

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 (fetch) and a specific resource (the full content of a ContexteTech resource), and pins the identifier's origin to search results. It differentiates itself from the search siblings, though it does not explicitly distinguish itself from the similarly named load_resource or get_download_link.

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 'by the id returned by search' implies the correct usage context and chains this tool after search, which is helpful. However, there is no explicit when-not guidance and no comparison against load_resource, which sounds like a plausible alternative for retrieving a resource.

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=true, so the safety profile is covered structurally. The description adds real value by disclosing the template mechanism ({{variable}} substitution) and the return shape ('ready-to-use prompt'), but says nothing about behavior on an unknown code or a missing/extra variable.

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 sentence, front-loaded with the verb and resource, with the placeholder mechanism parenthesized and the return value stated at the end. Nothing is wasted.

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-only tool with no output schema, the description supplies enough: input mechanism, output form, and annotated safety profile. Only error/edge-case behavior and how to discover valid codes are absent, which is a minor 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 both parameters are already documented ('Short code of the prompt', 'Values for each {{variable}}'). The description echoes the placeholder-to-key mapping without adding format rules (e.g. whether keys must match placeholders exactly), 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 ('Fill') and resource ('ContexteTech prompt template'), plus the placeholder syntax that defines the operation. It is unambiguous and no sibling (search, fetch, load_resource, etc.) is confusable with it, though the description never explicitly differentiates itself from them.

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

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

Usage is only implied: an agent infers it should call this when it has a template code and variable values. There is no statement of when to prefer it over alternatives (e.g. using search_resources to locate the code first) and no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description usefully adds that the link covers the 'whole' dataset and the exact serialization formats, but says nothing about link expiry, authentication requirements, or size limits — meaningful gaps for an openWorld download 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 scope qualifier ('whole dataset') comes before the format list. It is a fragment rather than a full sentence, but nothing is wasted.

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-only tool with full schema coverage and annotations, the definition is minimally adequate. It omits what the tool actually returns (a URL string?), whether that URL expires, and any permission requirements — gaps that matter since there is no output schema to compensate.

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%, and the format enum is fully documented in the schema, so the description's format list largely duplicates structured data. The 'code' parameter is only echoed as 'short code of the dataset', adding no syntax or lookup semantics beyond the schema — baseline 3 is correct.

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 ('download link') and resource ('whole ContexteTech dataset') and enumerates the output formats, so the agent knows exactly what it retrieves. It does not, however, distinguish itself from siblings like fetch or load_resource, which also deal with resource retrieval.

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 use this tool versus fetch or load_resource, nor any prerequisite information (e.g., whether the dataset must exist or be public). The agent must infer usage purely from the name and format 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?

Annotations already declare readOnly, non-destructive, openWorld, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape per resource type (dataset: description/licence/first rows; prompt: template/variables; context: system prompt/examples), which matters because there is no output schema. It omits error behavior for invalid codes, keeping it from a 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?

Two sentences, zero filler. The lookup key and an example code are front-loaded, and the payload breakdown is compressed into a tight list. The semicolon list is dense but readable; nothing is wasted.

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 no output schema, the description supplies what an agent most needs: the meaning of the short code and the return shape for each resource kind. Missing pieces are sibling differentiation and failure modes, which are minor given the annotation coverage.

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 'code' and 'rows' (default 10, max 50) are fully documented in the schema. The description only implicitly ties 'rows' to the dataset payload ('the first rows'), adding marginal meaning. 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?

States a specific verb and resource ('Load one ContexteTech resource by short code') and goes further by enumerating the three resource kinds and what each payload contains. It does not explicitly contrast with siblings like fetch or search_resources, but the singular 'one resource by short code' is distinctive enough to separate it from search tooling.

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: nothing says this is the follow-up call after search_resources or how it differs from the sibling 'fetch'. The example code implies a lookup flow but the routing decision is left entirely 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds the return shape (id, title, url), which is genuinely useful since no output schema exists, but says nothing about result limits, pagination, or ranking behavior.

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 sentences, zero waste, with the scope of the search front-loaded and the return fields following. Both sentences earn their place given the absence of an output schema.

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 tool this covers the essentials, and the return-field sentence compensates for the missing output schema. However, the failure to route between this tool and search_resources leaves a real gap for an agent choosing among siblings.

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 'query' parameter documented as 'Search words', so the schema carries the load. The description adds no query syntax, matching rules, or formatting guidance beyond what the schema provides, making the baseline 3 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?

States a specific verb (Search) and resource (ContexteTech catalogue of AI datasets, prompts and contexts), and names the returned fields. It does not, however, distinguish itself from the sibling tool search_resources, which an agent could easily confuse it with.

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 use this tool versus alternatives such as search_resources, fetch, or load_resource. The agent must infer usage from the name alone, which is risky given the overlapping sibling names.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value by enumerating the fields returned per match (code, title, type, language, licence, row count, description, page URL), which is meaningful behavioral context given there is no output schema.

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, front-loaded with the core action and scope, then the return shape. The type enumeration in sentence one is dense but informative rather than redundant; little waste overall.

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 a complete parameter schema and no output schema, the description adequately covers both the searchable domain and the return fields. The main omission is result count/pagination behavior, a minor gap for a search tool.

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

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

Schema description coverage is 100%, so the schema already documents query, type and language. The description adds only ambient context (types, 9 languages) that loosely maps to the type/language params but contributes no syntax, format or default details beyond the schema. 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 gives a specific verb (Search) and a well-scoped resource (the ContexteTech catalogue of AI building blocks), enumerating the content types it covers. An agent knows exactly what domain this returns, though it never explicitly distinguishes itself from the generic sibling 'search' 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?

There is no when-to-use guidance and no routing away from siblings such as 'search' or 'load_resource'. The usage is only implied by the tool's domain, leaving the agent to guess how this differs from the generic search sibling.

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