Services, prices, inquiries and free analytics, AI and Google visibility scans by JustIdea, Poland.
Scored across 8 tools
Each tool has a clearly distinct purpose: content retrieval (get_page, list_services, search_site), domain-specific scans (scan_ai_visibility, scan_analytics, scan_google_visibility), result fetching (get_scan_result), and inquiry submission (send_inquiry). Overlaps are hierarchical rather than ambiguous, and descriptions clarify boundaries well.
All tools use lower snake_case with a verb_noun structure (get_page, list_services, scan_*, search_site, send_inquiry). Minor variation in noun phrase length for scan tools remains predictable and readable.
Eight tools are well-scoped for a website/agency MCP: three content access tools, three scan types, one result fetcher, and one inquiry tool. No tool feels redundant, and the count matches the domain's needs.
The surface covers content discovery and retrieval, free scan initiation and result retrieval, and sales inquiry submission. While there is no dedicated blog or case study listing, get_page and search_site provide workable access, so no significant gaps or dead ends exist.
Full text of one justidea.agency page as Markdown: a service, a price list, the company profile, reviews, a blog article. Accepts a full URL or a path, e.g. "/pl/cennik/sklepy-internetowe/" or "https://justidea.agency/en/pricing/online-stores/". Only pages published on the site; use list_services or search_site to find the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL or path on justidea.agency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return format (Markdown full text) and the scope restriction that only published pages are reachable. It does not mention auth requirements or pagination/truncation behavior for long pages, which keeps it short of 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?
Three sentences, front-loaded with the return value, then accepted input formats, then discovery guidance. The examples are concrete and each sentence carries distinct information with 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?
With no output schema, the description correctly supplies the return format (Markdown full text) and the input scope. For a single-parameter read tool with annotations covering safety, nothing needed 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% and the single url parameter is documented with a max length, so the baseline is 3. The description goes beyond that by giving two concrete accepted formats, a path ('/pl/cennik/sklepy-internetowe/') and an absolute URL, which clarifies the dual-input behavior the schema only hints at.
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+output format ('Full text of one justidea.agency page as Markdown') and enumerates the page types it covers (service, price list, profile, reviews, blog article). An agent can distinguish it from list_services and search_site without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'use list_services or search_site to find the URL', and constrains scope with 'Only pages published on the site'. This names the alternatives and the condition under which each is preferred, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Result of a scan started with scan_analytics, scan_ai_visibility or scan_google_visibility that was still running. Returns the same grade and problem list; sends the full report by e-mail if it has not gone yet. Scan IDs expire after 2 days.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan_id returned by the scan tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=true; the description explains exactly why a read-shaped tool mutates state by disclosing the e-mail side effect ('sends the full report by e-mail if it has not gone yet') and makes the idempotency comprehensible via 'if it has not gone yet'. It also adds the 2-day scan ID expiry, a hard behavioral constraint not present in the schema or 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?
Three compact clauses: what it returns, the e-mail side effect, the expiry rule. Purpose leads and nothing is padded, though the opening noun phrase ('Result of a scan started with ... that was still running') is slightly tangled and would read better as an imperative.
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-value burden and does so by naming the payload ('same grade and problem list') and the e-mail delivery. It omits what happens if the scan is still incomplete or what an expired/invalid scan_id produces, which are the remaining gaps for a 1-parameter retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (type, pattern, and 'the scan_id returned by the scan tool'), so the baseline is 3. The description earns one more point by adding the parameter's lifetime semantics — scan IDs are invalid after 2 days — which tells the agent when the value it holds will stop working.
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 retrieval action (get the result of a previously started scan) and explicitly names the three sibling tools that produce those scans (scan_analytics, scan_ai_visibility, scan_google_visibility), so an agent can immediately distinguish 'start a scan' from 'fetch a scan's result'. It also pins the scope: results for scans that were still running when the scan tool returned.
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 context for when this tool applies — after one of the three named scan tools returned a still-running scan. It does not state what to do if the scan is not yet finished, nor whether to poll, wait, or how often to call, so the guidance stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List JustIdea Agency services with the published starting ("from") prices and links. Returns the price list (12 service categories, each with its packages) and every service page with its short description. All prices are net (VAT excluded) and exactly as published on justidea.agency. Use get_page for the full scope of a service and search_site for city pages, case studies and articles.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Site language: "pl" (prices in PLN) or "en" (prices in EUR for clients outside Poland). | pl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable domain context beyond that: 12 categories each with packages, prices are net/VAT excluded and exactly as published. It does not mention pagination or response ordering, which is a minor 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?
Three sentences, front-loaded with what is listed and returned, followed by a useful price caveat and then sibling routing. 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?
No output schema exists, so the description carrying the return shape (price list plus service pages with short descriptions) and the VAT/currency caveat is exactly the right compensation. An agent has everything needed to call it 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?
Schema coverage is 100% and the enum parameter already documents pl/en and the PLN vs EUR currency implication. The description adds no parameter-level detail, so the schema does the heavy lifting and a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (JustIdea Agency services) plus the exact data returned in scope (starting/from prices and links). The sibling tools get_page and search_site cover different content types, and the description makes the boundary explicit.
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 routing: use get_page for the full scope of a service and search_site for city pages, case studies and articles. This names the alternatives and the condition that selects each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free check of how ready a website is for AI assistants and AI search (ChatGPT, Perplexity, Gemini, Claude): whether their crawlers get in (robots.txt, firewalls), whether the content is readable without JavaScript, structured data, llms.txt and the signals models use to cite a source. Takes about 10-30 seconds. Returns the grade (A-F), the score and the list of problems, without fixes. The full report with step-by-step fixes and a PDF is sent by JustIdea Agency to the user's e-mail. Use only details the user gave you: never invent or guess an e-mail address. Before calling, tell the user the report goes to their e-mail and ask for consent under the privacy policy (https://justidea.agency/en/privacy-policy/); set zgoda to true only after they agree. At most 2 scans per e-mail address per day. If it returns status "running", call get_scan_result with the scan_id after 30-60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to scan: a domain or URL, e.g. "mystore.com". Only the home domain is used. | |
| name | No | Optional. The user's first name, only if they gave it. | |
| Yes | The user's own e-mail address. The full report with fixes is sent there, and only there. | ||
| phone | No | Optional. The user's phone number, only if they gave it and want a call about the results. | |
| zgoda | Yes | Must be true: the user agreed to receive the report by e-mail, to be contacted by JustIdea about the results, and to the processing of this data under the privacy policy. | |
| language | No | Report language. Use "pl" for Polish-speaking users, "en" for everyone else. | pl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that the report is e-mailed by JustIdea Agency (third-party data flow), the ~10-30s runtime, a 2-per-e-mail-per-day rate limit, and that results arrive without fixes until the full report. The only disclosure missing is whether the scan is billed or how long emailed reports take, so a 4 rather than a 5 against the already-informative openWorldHint/readOnlyHint=false 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 and return format, then constraints, then the fallback routing. Every sentence carries an operational fact, but the prose is dense and mixes what-it-does, consent, rate limits, and error handling into a single run-on block, slightly hurting scanability.
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 compensates by naming the return payload (grade A-F, score, problems list) and the 'running' status that routes to get_scan_result. Consent, rate limits, timing, and the e-mail delivery channel are all covered, leaving nothing essential for a correct 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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: zgoda is a consent gate the agent must obtain before setting true, and email must be the user's own real address rather than a guess. That materially shapes how url, email, and zgoda get populated.
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 (scan/check) and resource (website AI visibility) and enumerates exactly what is inspected: crawler access via robots.txt/firewalls, JS-free readability, structured data, llms.txt, and citation signals. An agent can distinguish this from scan_analytics, get_page, or search_site 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?
Explicit when-to-use and how-to-use: tell the user the report goes to e-mail, obtain consent under the named privacy policy, set zgoda only after agreement, never invent an e-mail, and poll get_scan_result with the scan_id if status is 'running'. It even names the concrete alternative and the delay (30-60s) for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free check of how a website or online store measures traffic and sales: Google Tag Manager, GA4 and e-commerce events, consent banner and Consent Mode v2, server-side tagging, Meta Pixel and Conversions API. A real browser visits the site (home, product page, cart) for up to 90 seconds. Returns the grade (A-F), the score and the list of problems, without fixes. The full report with step-by-step fixes and a PDF is sent by JustIdea Agency to the user's e-mail. Use only details the user gave you: never invent or guess an e-mail address. Before calling, tell the user the report goes to their e-mail and ask for consent under the privacy policy (https://justidea.agency/en/privacy-policy/); set zgoda to true only after they agree. At most 2 scans per e-mail address per day. If it returns status "running", call get_scan_result with the scan_id after 30-60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to scan: a domain or URL, e.g. "mystore.com". Only the home domain is used. | |
| name | No | Optional. The user's first name, only if they gave it. | |
| Yes | The user's own e-mail address. The full report with fixes is sent there, and only there. | ||
| phone | No | Optional. The user's phone number, only if they gave it and want a call about the results. | |
| zgoda | Yes | Must be true: the user agreed to receive the report by e-mail, to be contacted by JustIdea about the results, and to the processing of this data under the privacy policy. | |
| language | No | Report language. Use "pl" for Polish-speaking users, "en" for everyone else. | pl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: a real browser visits home/product/cart for up to 90 seconds, the scan returns grade/score/problems with no fixes, the full PDF report is sent by the agency, and there is a per-email daily cap plus an asynchronous 'running' state. This is unusually rich behavioral context for a non-idempotent open-world 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?
Front-loads what is scanned, then return shape, then the consent/rate-limit workflow, then the polling fallback. It is long, but nearly every sentence carries a distinct operational instruction; only the enumeration of tracking technologies is dense enough to slow reading.
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 complex, non-idempotent, open-world tool with no output schema, the description still explains the return payload (grade, score, problems list, e-mailed PDF), the async polling path, consent obligations, and limits. An agent has everything needed to call it correctly and legally.
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 genuine meaning: the consent semantics of zgoda (only true after explicit agreement), the rule that email must be user-supplied and is the sole delivery target, and the note that only the home domain of url is used. It reinforces rather than merely restates 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?
Names a specific action (free analytics/tracking scan) and enumerates exactly what is checked: GTM, GA4 and e-commerce events, consent banner/Consent Mode v2, server-side tagging, Meta Pixel and Conversions API. This is clearly distinct from siblings like get_scan_result (retrieval) and scan_ai_visibility (different domain).
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 preconditions (tell the user the report goes to their e-mail, get consent, set zgoda only after agreement), a rate limit (max 2 scans per e-mail per day), a constraint (never invent an e-mail), and a routing rule (if status is 'running', call get_scan_result after 30-60s). Alternatives and when-not conditions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free check of whether Google can index a website well: Googlebot access in robots.txt and on the server, noindex, canonical, http-to-https and www redirects, the sitemap and whether its URLs answer 200, titles, meta descriptions, H1, structured data, mobile viewport, hreflang and Core Web Vitals from real Chrome users. Takes about 15-60 seconds. Returns the grade (A-F), the score and the list of problems, without fixes. When available, it also returns an Ahrefs estimate of the domain in Google (ranking keywords, monthly organic traffic, Domain Rating, referring domains). These numbers are estimates, not Search Console data, they do not affect the grade, and they are sometimes temporarily unavailable. The report is in Polish. The full report with step-by-step fixes and a PDF is sent by JustIdea Agency to the user's e-mail. Use only details the user gave you: never invent or guess an e-mail address. Before calling, tell the user the report goes to their e-mail and ask for consent under the privacy policy (https://justidea.agency/en/privacy-policy/); set zgoda to true only after they agree. At most 2 scans per e-mail address per day. If it returns status "running", call get_scan_result with the scan_id after 30-60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website to scan: a domain or URL, e.g. "mystore.com". Only the home domain is used. | |
| name | No | Optional. The user's first name, only if they gave it. | |
| Yes | The user's own e-mail address. The full report with fixes is sent there, and only there. | ||
| phone | No | Optional. The user's phone number, only if they gave it and want a call about the results. | |
| zgoda | Yes | Must be true: the user agreed to receive the report by e-mail, to be contacted by JustIdea about the results, and to the processing of this data under the privacy policy. | |
| language | No | Report language. Use "pl" for Polish-speaking users, "en" for everyone else. | pl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description adds rich context well beyond them: 15-60s runtime, email delivery of the full report, Polish-language output, rate limits, privacy-consent requirement, and that Ahrefs figures are estimates that can be temporarily unavailable and do not affect the grade. No contradiction with 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?
Purpose and core behavior are front-loaded, and the operational/consent/async rules are grouped logically. It is long, but nearly every sentence carries actionable information; minor tightening of the Ahrefs and delivery sentences would make it cleaner.
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 still covers return values (grade A-F, score, problem list, optional Ahrefs estimates) and the asynchronous 'running' flow. An agent has everything needed to call correctly, handle consent, and follow up.
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 meaning the schema lacks: zgoda is consent-gated by the privacy policy step and must only be set after the user agrees, and language maps to Polish vs. everyone else. It adds value without needing to restate field formats.
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 (a free Google visibility/indexing scan) and enumerates the exact checks performed (robots.txt, noindex, canonical, redirects, sitemap, titles, structured data, CWV, etc.). It is instantly distinguishable from scan_ai_visibility and scan_analytics.
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?
Explicit when-to-use and operational guidance: obtain consent before calling, set zgoda=true only after agreement, use only user-supplied details and never invent an e-mail, respect the max 2 scans per e-mail/day, and if status is 'running', call get_scan_result with the scan_id after 30-60s. Names the sibling tool to use for async retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search justidea.agency pages by titles, descriptions and section headings. Polish and English queries both work. Returns titles, URLs and descriptions; read a result with get_page.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Limit to one kind of page. | |
| limit | No | ||
| query | Yes | What to look for, e.g. "PrestaShop migration", "sklep internetowy Kraków", "SEO price". | |
| language | No | Limit to one site language. | any |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false already declaring safety and scope, the description adds useful context beyond annotations: the searchable fields, bilingual query support, and the shape of results. It omits pagination/limit behavior, which is left to the 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?
Three tight sentences, front-loaded with what is searched, then language support, then result shape and follow-up. No filler or repetition of the title.
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 usefully names the return fields (titles, URLs, descriptions) and the next-step tool, covering the essentials for a 4-param search. It could say more about limit/result-count behavior to be fully complete.
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 75%, so kind, language, and query are already documented in the schema. The description adds the language behavior ('Polish and English queries both work') but contributes nothing on kind or limit beyond the enum, so it stays at baseline.
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 (justidea.agency pages) plus the fields searched (titles, descriptions, section headings), which is concrete and distinguishable from siblings like get_page and list_services. An agent knows exactly what this tool retrieves without opening the 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?
Clearly signals the follow-up path ('read a result with get_page'), routing the agent between search and retrieval. It does not state when not to use it versus list_services or send_inquiry, so it stops short of full explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a sales inquiry to JustIdea Agency (Kraków, Poland) on behalf of the user. It goes to the agency CRM and the sales team, the sender gets a short confirmation e-mail, and a person replies within one business day. Use only details the user gave you. Never invent a name, e-mail or phone number. Before sending, show the user what will be sent and ask for consent to data processing under the privacy policy (https://justidea.agency/en/privacy-policy/); set zgoda to true only after they agree. Budgets are in PLN net ("tys. zł" = thousand PLN). At most 2 inquiries per e-mail address per day. Urgent matters: phone +48 12 400 40 40.
| Name | Required | Description | Default |
|---|---|---|---|
| imie | Yes | Full name of the person sending the inquiry. | |
| Yes | Email address for the reply. | ||
| firma | No | Company name, optional. | |
| zgoda | Yes | Must be true: the user agreed to the processing of the data in this inquiry under the privacy policy. | |
| budzet | Yes | Budget range, exactly one of the listed values, and it must match the service. One-off projects ("sklep", "strona", "audyt", "kreacja", "inne") take a project budget: "do 15 tys. zł", "15-40 tys. zł", "40-80 tys. zł", "80-150 tys. zł", "150-300 tys. zł", "powyżej 300 tys. zł", "jeszcze nie wiem". Monthly services ("seo", "wizytowka", "kampanie", "marketing", "content", "opieka") take a monthly budget: "do 2 tys. zł", "2-6 tys. zł", "6-15 tys. zł", "15-40 tys. zł", "40-100 tys. zł", "powyżej 100 tys. zł", "jeszcze nie wiem". If the user does not know the budget, use "jeszcze nie wiem" instead of guessing. | |
| strona | No | Current website or online store address, optional. | |
| usluga | Yes | What the inquiry is about: "sklep" = Sklep internetowy; "strona" = Strona internetowa; "seo" = Pozycjonowanie SEO; "wizytowka" = Wizytówka Google i Bing; "kampanie" = Kampanie reklamowe; "marketing" = Marketing, pełny zakres; "content" = Content marketing i treści; "opieka" = Opieka i rozwój serwisu; "audyt" = Audyt; "kreacja" = Identyfikacja i kreacja; "inne" = Coś innego. | |
| telefon | Yes | Phone number with at least 9 digits, country code welcome. | |
| wiadomosc | Yes | The request in the user's own language, at least two sentences: what they need, scope, deadline. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description goes well beyond: it discloses where the inquiry lands (agency CRM and sales team), that the sender receives a confirmation e-mail, a one-business-day reply SLA, a rate limit of 2 inquiries per e-mail per day, and the consent/privacy-policy requirement. Rich behavioral context.
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?
Dense but front-loaded: purpose and delivery mechanics first, then constraints, then consent and budget notes. Every sentence carries operational value, though the volume of guidance makes it longer than strictly minimal.
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 9-parameter, 7-required mutation with no output schema and openWorld semantics, the description supplies everything an agent needs: consent sequencing, data-honesty rules, budget units, rate limit, alternative contact channel, and expected outcome (confirmation e-mail + reply within one business day).
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 description adds real value beyond the schema: budgets are PLN net with 'tys. zł' = thousand PLN, and zgoda must be set true only after the user agrees to data processing. These clarify units and the consent gate's intent.
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 ('Send a sales inquiry to JustIdea Agency') with clear scope. This is instantly distinguishable from all siblings (get_page, scan_*, list_services, search_site), which are read/scan operations.
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 only details the user gave, never invent contact data, show the user what will be sent and obtain consent before sending, and route urgent matters to phone +48 12 400 40 40. Concrete when-to-use conditions and constraints are all present.
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.
send_inquiry3 fields changedInput schema / properties / budzet / descriptionPrevious value: -"Budget range, exactly one of the listed values, and it must match the service. One-off projects (\"sklep\", \"strona\", \"audyt\", \"kreacja\", \"inne\") take a project budget: \"do 15 tys. zł\", \"15-40 tys. zł\", \"40-80 tys. zł\", \"80-150 tys. zł\", \"150-300 tys. zł\", \"powyżej 300 tys. zł\", \"jeszcze nie wiem\". Monthly services (\"seo\", \"kampanie\", \"marketing\", \"content\", \"opieka\") take a monthly budget: \"do 2 tys. zł\", \"2-6 tys. zł\", \"6-15 tys. zł\", \"15-40 tys. zł\", \"40-100 tys. zł\", \"powyżej 100 tys. zł\", \"jeszcze nie wiem\". If the user does not know the budget, use \"jeszcze nie wiem\" instead of guessing."New value: +"Budget range, exactly one of the listed values, and it must match the service. One-off projects (\"sklep\", \"strona\", \"audyt\", \"kreacja\", \"inne\") take a project budget: \"do 15 tys. zł\", \"15-40 tys. zł\", \"40-80 tys. zł\", \"80-150 tys. zł\", \"150-300 tys. zł\", \"powyżej 300 tys. zł\", \"jeszcze nie wiem\". Monthly services (\"seo\", \"wizytowka\", \"kampanie\", \"marketing\", \"content\", \"opieka\") take a monthly budget: \"do 2 tys. zł\", \"2-6 tys. zł\", \"6-15 tys. zł\", \"15-40 tys. zł\", \"40-100 tys. zł\", \"powyżej 100 tys. zł\", \"jeszcze nie wiem\". If the user does not know the budget, use \"jeszcze nie wiem\" instead of guessing."Input schema / properties / usluga / descriptionPrevious value: -"What the inquiry is about: \"sklep\" = Sklep internetowy; \"strona\" = Strona internetowa; \"seo\" = Pozycjonowanie SEO; \"kampanie\" = Kampanie reklamowe; \"marketing\" = Marketing, pełny zakres; \"content\" = Content marketing i treści; \"opieka\" = Opieka i rozwój serwisu; \"audyt\" = Audyt; \"kreacja\" = Identyfikacja i kreacja; \"inne\" = Coś innego."New value: +"What the inquiry is about: \"sklep\" = Sklep internetowy; \"strona\" = Strona internetowa; \"seo\" = Pozycjonowanie SEO; \"wizytowka\" = Wizytówka Google i Bing; \"kampanie\" = Kampanie reklamowe; \"marketing\" = Marketing, pełny zakres; \"content\" = Content marketing i treści; \"opieka\" = Opieka i rozwój serwisu; \"audyt\" = Audyt; \"kreacja\" = Identyfikacja i kreacja; \"inne\" = Coś innego."Input schema / properties / usluga / enumPrevious value: -[
- "sklep",
- "strona",
- "seo",
- "kampanie",
- "marketing",
- "content",
- "opieka",
- "audyt",
- "kreacja",
- "inne"
-]New value: +[
+ "sklep",
+ "strona",
+ "seo",
+ "wizytowka",
+ "kampanie",
+ "marketing",
+ "content",
+ "opieka",
+ "audyt",
+ "kreacja",
+ "inne"
+]scan_google_visibilityget_scan_resultscan_ai_visibilityscan_analyticsget_pagelist_servicessearch_sitesend_inquiryScans any public website for SEO, AI search, trust, conversion and speed, and lists our prices.
SEO audits and AI crawler checks. Honest findings only; no invented scores.
SEO, AEO and GEO audits, rank tracking, AI-citation scans and WordPress editing for any site.
Full-cycle SEO automation for AI agents: technical audits, SEO articles, machine-readable pricing.
Add one secure layer between your agents and this server.
