Search the curated directory of professional muralists and street artists in Europe.
Scored across 4 tools
The tool set contains two near-duplicate pairs: `search`/`search_muralists` both search the directory, and `fetch`/`get_muralist_profile` both retrieve a full profile by id. The descriptions attempt to differentiate free-text search from structured filtering and generic fetching from domain-specific retrieval, but an agent could easily pick either member of each pair and get equivalent results.
Naming mixes generic single verbs (`fetch`, `search`) with domain-specific verb_noun names (`get_muralist_profile`, `search_muralists`). The lack of a consistent convention reinforces the ambiguity between the generic and domain-specific tools.
Four tools would be reasonable for a directory, but the effective surface is only two distinct operations duplicated across generic and domain-specific names. The count feels slightly padded rather than well-scoped.
The directory domain is largely covered: agents can search by free text or structured filters and retrieve full profiles with portfolio and quote information. Minor gaps might include browsing all artists or a dedicated quote-request operation, but core lookup workflows are supported.
Retrieve the full text of one Muralists directory profile by id, for citation. Ids come from the search tool.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The profile id (slug) returned by search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | Absolute canonical URL of the profile page. |
| text | Yes | Plain-text rendering of the profile (Dutch). |
| title | Yes | |
| metadata | Yes | Extra fields: city, styles, pro status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only safety profile (readOnlyHint true, openWorldHint false). The description adds that it returns the full profile text and is intended for citation, but does not discuss output size, rate limits, or any special handling. This is acceptable but not rich.
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, front-loaded with the action and resource, and the id-source hint is placed second. No filler or repetition.
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 fetch with an output schema, the definition is nearly complete. The main gap is that it does not explain how fetch relates to the similarly named sibling get_muralist_profile, so an agent may be uncertain which to invoke.
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 coverage is 100% and the id parameter is fully described as a slug returned by search. The description repeats this same provenance rather than adding new parameter-level meaning, so it earns the baseline score.
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 a specific verb and resource: retrieve the full text of one Muralists directory profile by id, and adds the purpose (citation). However, it does not differentiate fetch from the sibling get_muralist_profile, which appears to target the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: ids come from the search tool and the use case is citation. It does not explicitly state when not to use this tool or name alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full profile of a specific muralist from the Muralists directory: bio, styles, portfolio of realized works with locations, typical project types, and how to request a quote. Use after search_muralists to get details on a candidate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The muralist's profile slug — the stable public identifier returned as `id` by search_muralists and used in the profile URL. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| bio | Yes | The artist's own statement, in Dutch. |
| city | Yes | |
| name | Yes | |
| works | Yes | Realized murals with location and year. |
| is_pro | Yes | Active paying member of the directory. Pro profiles rank first. |
| region | No | |
| styles | Yes | |
| country | Yes | ISO 3166-1 alpha-2 country the artist is based in. |
| summary | Yes | |
| contact_url | Yes | Where to reach this artist — currently the public profile page. |
| profile_url | Yes | |
| years_active | No | |
| how_to_commission | Yes | |
| accepts_commissions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the safe read-only nature is established. The description adds that it returns a 'full profile' with specific sections, which is useful. However, it doesn't disclose details like whether profile data is aggregated from external sources or if portfolio images are included, though for a read-only profile tool this gap is acceptable.
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 tool's purpose and content, then a clear usage directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and clear schema documentation, the description covers what the tool does and when to use it. The only minor gap is not explicitly stating the return format, but the description lists the profile sections which implies the structure.
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 documents the id parameter thoroughly, including its nature as a slug, stability, source, and URL usage. The description doesn't repeat this but complements by indicating the id comes from search_muralists. With one well-documented parameter, the baseline is elevated.
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 gets a full profile of a specific muralist, enumerating the content (bio, styles, portfolio, project types, quote request). It distinguishes itself from the sibling search_muralists by specifying 'a specific muralist' and directing use 'after search_muralists'.
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 to use after search_muralists to get details on a candidate. This gives clear sequencing guidance and differentiates from the search alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Muralists directory of muralists and street artists by free text (name, city, style). Returns matching artists with their profile URLs. Use fetch with a returned id to read the full profile.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search query, e.g. 'lettering artist Utrecht'. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, so no side-effect disclosures are needed. The description adds behavioral value by clarifying that results are limited to matching artists and profile URLs and that full profile content requires a separate fetch call – a useful boundary beyond the annotations. No contradictions.
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: the first front-loads the action and scope, the second adds the return format and next step. Every word earns its place; no redundancy.
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 one required parameter, a read-only annotation, and an existing output schema, the description supplies the essential usage flow and return shape. The only remaining gap is the relationship to the search_muralists sibling, which prevents a 5.
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 only parameter (query) is already fully described in the schema (100% coverage), giving a baseline of 3. The tool description enriches this by specifying what the free-text query can target – name, city, style – which is not present in the schema. Thus it earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource – 'Search the Muralists directory' – and enumerates searchable facets (name, city, style). It distinguishes itself from fetch/get_muralist_profile by noting that only profile URLs are returned and that fetch is needed for full profiles. However, it does not differentiate from the sibling search_muralists, leaving ambiguity between the two search 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?
It provides a concrete workflow: run a free-text search, receive profile URLs, then 'Use fetch with a returned id to read the full profile.' This is clear context for when this tool fits. It does not state explicit exclusions or when to prefer search_muralists, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a curated directory of muralists and street artists in Europe. Filter by country, city/region and style (e.g. abstract, figurative, lettering, photorealistic, geometric). Returns matching artists with portfolio highlights and profile URLs. Use this when someone wants to find, hire, or commission a mural artist.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of artists to return (1-10). | |
| query | No | Free text over name, tagline, bio, city and styles. | |
| style | No | Style label, e.g. abstract, figurative, lettering, photorealistic, geometric. | |
| region | No | City, province or region the artist is based in, e.g. 'Rotterdam', 'Noord-Holland', 'Berlin'. Matches city or region. | |
| country | No | Country, as an ISO 3166-1 alpha-2 code ('DE') or its Dutch name ('Duitsland'). By default matches where the artist is BASED. | |
| include_travel | No | With `country`: also return artists who will WORK there without being based there (they named the country, said 'all of Europe', or have a current or upcoming travel period there). |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| total_matches | Yes | How many artists matched before the limit was applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-world behavior are covered. The description adds the curated/Europe scope and return contents, but does not disclose auth needs, rate limits, pagination, or other behavioral limits, making 3 appropriate.
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 sentences, front-loaded with purpose and scope, followed by filters, return contents, and usage trigger. Every sentence contributes and there is no 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?
Given the annotations and output schema, the description is largely complete: it covers purpose, filters, returns, and a clear use case. It omits sibling routing and the include_travel/limit nuances, though the schema handles those details, leaving only 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 all six parameters are already documented in the schema. The description restates the main filters and style examples but adds no syntax, matching rules, or edge-case meaning 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?
States a specific verb and resource: "Search a curated directory of muralists and street artists in Europe," with clear geographic and domain scope. It does not explicitly distinguish itself from siblings like get_muralist_profile or generic search, so it falls short of 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?
Provides a clear usage trigger: "Use this when someone wants to find, hire, or commission a mural artist." It does not state when not to use it or name alternatives, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_muralists6 fields changedInput schema / properties / countryAdded value: +{
+ "description": "Country, as an ISO 3166-1 alpha-2 code ('DE') or its Dutch name ('Duitsland'). By default matches where the artist is BASED.",
+ "type": "string"
+}Input schema / properties / include_travelAdded value: +{
+ "description": "With `country`: also return artists who will WORK there without being based there (they named the country, said 'all of Europe', or have a current or upcoming travel period there).",
+ "type": "boolean"
+}Input schema / properties / region / descriptionPrevious value: -"Dutch city, province or region, e.g. 'Rotterdam', 'Noord-Holland'. Matches city or region."New value: +"City, province or region the artist is based in, e.g. 'Rotterdam', 'Noord-Holland', 'Berlin'. Matches city or region."Output schema / properties / results / items / properties / city / descriptionPrevious value: -"Dutch city the artist is based in."New value: +"City the artist is based in."Output schema / properties / results / items / properties / countryAdded value: +{
+ "description": "ISO 3166-1 alpha-2 country the artist is based in.",
+ "type": "string"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "id",
- "name",
- "city",
- "styles",
- "summary",
- "notable_works",
- "profile_url",
- "accepts_commissions"
-]New value: +[
+ "id",
+ "name",
+ "city",
+ "country",
+ "styles",
+ "summary",
+ "notable_works",
+ "profile_url",
+ "accepts_commissions"
+]fetchget_muralist_profilesearchsearch_muralistsFind AI tools, AI agencies and AI freelancers in Europe from the KI-Radar24 directory.
European directory of freight carriers: find carriers by route, equipment and certificates.
European maps, geocoding and routing: places, routes, travel times, reachable areas and maps.
Find and compare coworking spaces and offices in 300+ European cities; get office quotes.
Add one secure layer between your agents and this server.
