Search and load AI datasets, prompts and few-shot contexts from the ContexteTech catalogue.
Scored across 6 tools
Two clear overlapping pairs exist: 'search' vs 'search_resources' both search the catalogue, and 'fetch' vs 'load_resource' both retrieve resource content. The descriptions hint at differences (search returns id/title/url, search_resources returns up to 15 detailed matches; fetch takes an id, load_resource takes a code/URL), but an agent could easily pick the wrong one of each pair.
All names are lower_snake_case, which is consistent. However, some are bare verbs (fetch, search) while others are verb_noun (estimate_cost, fill_prompt, load_resource, search_resources), a minor stylistic deviation rather than a real inconsistency.
Six tools is a sensible scope for a catalogue-browsing server (search, load, fetch, fill, cost estimate). It is slightly padded by the redundant search/search_resources and fetch/load_resource pairs that could be merged, keeping it just under a clean scope.
The read-only lifecycle for a resource catalogue is well covered: discover (search), inspect (load_resource/fetch), use (fill_prompt) and cost (estimate_cost). It lacks any listing/browse-by-category or write operations, but for a read-only catalogue those are minor gaps an agent can work around.
Estimate in euros what a ContexteTech resource costs to run with common AI models, from the week's list prices. Use it when the user asks about cost, budget or the cheapest model. For a prompt or context: input and output tokens, cost per call for each model and batch discount; for a dataset: cost of one pass over all rows and a fine-tuning estimate on rented GPUs (hours and offers); for a model: memory (VRAM) needed and GPU offers that fit. Returns available: false with a note when no estimate exists for that type.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Short code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, non-destructive safety profile and openWorldHint. The description goes further by disclosing the per-input-type return content and, importantly, the degradation behavior ('Returns available: false with a note when no estimate exists'), which the agent could not infer from 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?
Front-loaded with purpose, then usage trigger, then a compact breakdown of outputs per input type, ending with the failure case. Dense but every clause carries information; the per-type enumeration is slightly list-heavy but justified by 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?
With no output schema, the description carries the return burden and does so by enumerating what each resource type yields plus the 'available: false' fallback. The remaining gap is that the required 'code' parameter's format and its role in selecting the resource type are left unexplained.
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 baseline is 3. The single 'code' parameter is described only as 'Short code' in the schema, and the description implies the code selects among three resource types (prompt/context, dataset, model) but never explains the code format or how type is determined. It adds marginal value, not compensating detail.
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 (estimate), resource (ContexteTech resource running cost), unit (euros), and data source (the week's list prices). This clearly distinguishes it from siblings like fetch, search, and load_resource, which have no cost dimension.
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 says when to use it: 'when the user asks about cost, budget or the cheapest model.' Clear trigger context, though no exclusions or alternative routing are named (no sibling covers cost, so that omission is minor).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content of a ContexteTech resource by the id returned by search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Resource id or short code |
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.
Fill a ContexteTech prompt template and return the ready-to-send text, nothing else. Use it when the user wants a prompt applied to their own case; call load_resource first if you need the template or the exact variable names. 'variables' maps each {{name}} of the template to its text value; extra keys are ignored. Fails with an error if the code is unknown, if the resource is not a prompt, or if a template variable is missing (the error lists the missing names).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Short code of the prompt | |
| variables | Yes | Values for each {{variable}} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing error behavior (unknown code, non-prompt resource, missing variable) and that missing-variable errors enumerate the missing names, which an agent can use to self-correct. It stops short of describing pagination/output format details, but the return contract is stated.
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?
Four tight sentences, front-loaded with purpose and output, then usage, then parameter semantics, then failure modes. No sentence is filler; each adds a distinct fact.
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?
Covers purpose, when-to-use, the sibling alternative, variable semantics, and the full failure surface including error content. With 2 required params and no output schema, nothing an agent needs to invoke 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: variables map each {{name}} placeholder to its text value and extra keys are silently ignored. That is behavior the schema's generic 'Values for each {{variable}}' does not convey.
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 ('Fill a ContexteTech prompt template') plus the exact output ('ready-to-send text, nothing else'). It also names the sibling load_resource for a related need, so an agent can distinguish this tool from its neighbors without inspecting 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?
Gives an explicit when-to-use condition ('when the user wants a prompt applied to their own case') and routes the agent to load_resource when it needs the template or exact variable names. Both the trigger and the alternative are stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one ContexteTech resource, usually right after search_resources or when the user gives a code or page URL. Accepts the short code (end of the page URL, e.g. 'jr6t0n'), 'author/name', or 'code#v2' for a fixed version. Always returns title, type, licence, language, source, version and page URL; plus, for a dataset, the total number of rows, the first rows (default 10, max 50); for a prompt, the template and its {{variables}} (then call fill_prompt); for a context, the system prompt, knowledge and examples. The result ends with a Source line (resource, author, original data source, publisher, licence): citing it with its links is required. Fails with an error if the code does not exist or the resource is private.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Short code (end of the resource URL) | |
| rows | No | Dataset rows to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it discloses the per-type return contract (dataset rows with default 10/max 50, prompt template plus {{variables}}, context system prompt/knowledge/examples), the mandatory Source citation line, and the two failure modes (nonexistent code, private resource). That is unusually rich behavioral 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?
Front-loaded with purpose and trigger, and each subsequent clause carries distinct information (formats, return shape, citation duty, failures). It is a dense run-on block rather than cleanly separated points, which slightly hurts scanability but no sentence 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?
With no output schema, the description carries the full burden of describing return values and does so per resource type, plus error behavior and citation obligations. Nothing needed 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it documents the three accepted code formats (short code, 'author/name', 'code#v2' for pinned versions) and restates the rows default/max. The version-pinning format in particular is not in 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?
States a specific verb+resource ('Read one ContexteTech resource') and immediately distinguishes itself from sibling search_resources by describing the post-search retrieval role. An agent can separate it from search, fetch, and fill_prompt without opening any 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 triggering conditions ('usually right after search_resources or when the user gives a code or page URL') and routes onward to fill_prompt for prompts. The alternative-tool relationship is named rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the ContexteTech catalogue of AI datasets, prompts and contexts. Returns results with id, title and url.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search words |
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.
Search the ContexteTech catalogue of AI building blocks: fine-tuning and evaluation datasets (chat, DPO, agent traces), prompts, few-shot contexts, MCP servers, models and more, many grounded in official European sources, in 9 languages. Use it first when the user needs AI training or evaluation data, a prompt, a context or an AI component, then call load_resource with a returned code. Write the topic in a few words, in English or the content language; common topics are matched across French, English, German and Spanish (e.g. 'marine weather' finds 'météo marine'), and a type word such as 'dataset' or 'prompt' puts that type first. Resources matching every topic come first; weaker matches carry match: partial. Returns up to 15 matches, each with short code, title, type, language, licence, author, rows (datasets), description and page URL; when nothing matches, returns a short message suggesting how to rephrase.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional type: dataset, prompt, context, tool, model, agent, eval, rag… | |
| query | Yes | Search words, e.g. 'customs code' or 'GDPR' | |
| language | No | Optional content language: fr, en, es, de, it, nl, pt, sv, pl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial behavior beyond them: cross-language topic matching, type-word prioritization, ranking with exact matches first and 'match: partial' for weaker hits, a cap of 15 results, and a no-match rephrase message. This is unusually rich disclosure for a search 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?
The definition is a single dense paragraph but is well front-loaded, opening with what it searches before moving to usage, matching mechanics and return shape. It is on the long side, though nearly every clause carries actionable 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?
With no output schema, the description carries the full burden of describing returns and does so: up to 15 matches with code, title, type, language, licence, author, rows, description and page URL, plus the empty-result behavior. An agent has everything needed to call and interpret 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 100%, so the baseline is 3, and the description earns above it by adding usage semantics the schema lacks: write the topic in a few words, English or the content language, and a type word such as 'dataset' or 'prompt' forces that type first. It reinforces rather than merely repeats 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 gives a specific verb (Search) plus the resource (the ContexteTech catalogue of AI building blocks) and enumerates the content types it covers (datasets, prompts, contexts, MCP servers, models). It differentiates itself from the follow-up sibling load_resource by naming it, but does not distinguish itself from the sibling `search`, leaving one 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?
It states clearly when to reach for it ('Use it first when the user needs AI training or evaluation data, a prompt, a context or an AI component') and what to do next ('then call load_resource with a returned code'). It gives no explicit when-not or guidance for choosing between it and the sibling `search`/`fetch`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_download_linkestimate_costfetchfill_promptget_download_linkload_resourcesearchsearch_resourcesSearch, sample and query open reproducible datasets published as immutable Parquet with schemas.
Search and fetch curated AI agent skills, prompts and MCP servers.
Search and read the aicoolies catalog of AI and developer tools via a remote MCP knowledge graph.
Search and load AI agent skills. Free metadata; full content requires a Pro or Studio account.
Add one secure layer between your agents and this server.
