Describe a store's problem: get the matching service, its fixed price, and a request link.
Scored across 5 tools
Each tool targets a clearly distinct step: list the catalog, match a need to services, get one service's scope, prepare an order link, or inspect a website. The descriptions explicitly state boundaries ('does not determine eligibility', 'not a diagnosis') which removes overlap between match_service and list_services. No two tools appear interchangeable.
All names use a consistent snake_case resource_action pattern with an 'advisors_' server prefix (catalog_list_services, catalog_get_service, catalog_match_service, order_prepare_link, site_check_basics). Minor deviation: catalog uses '<domain>_<verb>' while site/order use '<domain>_<verb>_<object>', but the scheme stays readable and predictable.
Five tools is well-scoped for a routing/selection purpose: three catalog operations, one order handoff, one site inspection. Each tool earns its place with no redundant or filler entries.
The surface covers the full discovery-to-handoff lifecycle: list services, match a need, fetch details, and prepare an order link, plus a separate site-check capability. Gaps are minor and intentional (no order creation or eligibility confirmation, by design), which agents can work around via the returned links.
Use after a service is identified and the user needs its published scope, limits, commercial packages, sample, and terms. Does not determine eligibility or order.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: ar or en. | ar |
| service_id | Yes | One id returned by the list tool. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| service | Yes | |
| catalog_version | Yes | |
| catalog_fingerprint_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered structurally. The description adds a useful scope disclaimer (not eligibility, not ordering) but says nothing about auth requirements, caching, or why it is idempotent.
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 with zero filler; the usage trigger is front-loaded and the exclusion clause follows immediately. Every clause carries distinct 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 an output schema present, return values need no explanation, and the annotations cover safety semantics. Purpose, timing, and scope boundaries are all present; only the explicit sibling routing 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 description coverage is 100% with both parameters documented and enumerated, so the schema does the heavy lifting; the baseline of 3 applies. The description adds no syntax, default-language, or id-format guidance beyond what the schema states.
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 resource and enumerates the payload contents (published scope, limits, commercial packages, sample, terms), so the agent knows exactly what comes back. It implies single-service retrieval via 'after a service is identified' but never explicitly contrasts itself with advisors_catalog_list_services or advisors_catalog_match_service.
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?
'Use after a service is identified' states the triggering condition, and 'Does not determine eligibility or order' draws a clear exclusion boundary that routes eligibility questions and ordering elsewhere. It stops short of naming the alternative tools explicitly, so an agent must infer which sibling handles those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a user asks what Advisors AI offers. Returns exactly five public services; do not use it to infer fit or to create an order.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| services | Yes | |
| package_count | Yes | |
| service_count | Yes | |
| catalog_version | Yes | |
| deployed_channel | Yes | |
| attribution_status | Yes | |
| catalog_fingerprint_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the cardinality guarantee ('exactly five') and misuse boundaries, but does not discuss auth, rate limits, or pagination; with an output schema present, return format is handled elsewhere.
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 trigger, then the behavior and exclusions. Every clause 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 list tool with one fully specified parameter, rich annotations, and an output schema, the description supplies everything needed: purpose, trigger, exclusions, and cardinality. No critical context 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?
There is a single language parameter with 100% schema coverage, including an enum and description. The tool description adds no parameter meaning beyond what the schema provides, 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?
Explicitly states it returns exactly five public services and frames use as answering what Advisors AI offers. It distinguishes from sibling tools by ruling out inferring fit (match_service) and creating orders (order_prepare_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?
Gives a clear trigger ('when a user asks what Advisors AI offers') and two explicit exclusions ('do not use it to infer fit or to create an order'). It does not name the alternative tools to use instead, 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.
Use when the user describes a business need but has not chosen a service. Returns at most two deterministic routing suggestions; it is not a diagnosis or proof of fit.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | Business need only; do not include credentials or personal data. | |
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| question | No | |
| confidence | No | |
| claim_boundary | No | |
| scoring_method | Yes | |
| recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context: it returns at most two deterministic suggestions and is explicitly not a diagnosis or proof of fit. That sets expectations beyond the readOnlyHint and idempotentHint annotations, though it says nothing about how the match is performed or what the response looks like.
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 with zero waste: the first states the usage trigger and the second the output guarantee and its limits. It is front-loaded and every sentence 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?
Given the presence of an output schema and annotations that cover safety, the description supplies the key behavioral caveats (max two suggestions, not a proof of fit). It is complete enough to call correctly, with only the shape of the suggestions left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters, including the enum for language and the warning against credentials or personal data in the need field. The description adds no parameter-level detail, which is acceptable given the schema's completeness, but it means the description earns only the 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?
The description states a clear routing function: maps a described business need to a public service when no service has been chosen. It distinguishes the tool from catalog lookup siblings by describing the input condition, though it does not explicitly name alternatives.
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 an explicit trigger ('when the user describes a business need but has not chosen a service'), which naturally excludes cases where a service is already known. It does not name the sibling tools that would handle those alternative cases, so it falls 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.
Use only after the user explicitly selects a package returned by the service tool. Returns the ordinary login/request link; it does not create an order, confirm eligibility, or charge anything.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Request-page language: ar or en. | ar |
| package_id | Yes | Published package id returned by advisors_catalog_get_service. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| package | Yes | |
| request_url | Yes | |
| creates_order | Yes | |
| charges_customer | Yes | |
| attribution_status | Yes | |
| eligibility_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond the annotations: it does not create an order, confirm eligibility, or charge anything, which reassures the agent about lack of side effects. Auth requirements and rate limits are still unmentioned, but are not critical here.
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 with zero waste. The first sentence front-loads the usage prerequisite, and the second sentence states the return and explicitly clarifies what the tool does not do.
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 low-complexity, read-only tool with rich annotations, a full input schema, and an output schema, the description covers what the agent needs: when to use it and what it does not do. Return value details are appropriately left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds minimal parameter meaning beyond linking package_id to a package returned by the service tool. 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?
The description states a specific action: returns the ordinary login/request link for a selected package. It distinguishes the tool from order creation, eligibility confirmation, and charging, but does not explicitly name sibling tools that might be alternatives.
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 a clear prerequisite: use only after the user explicitly selects a package returned by the service tool. It also states what the tool does not do, which implicitly rules out using it for order creation or eligibility checks, but no named alternative is provided for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only when a user asks to inspect a public website. Measures bounded page, robots, structured-data, sitemap, and experimental llms.txt signals. It does not measure AI mentions, rank, visibility, firewall passage, or sales.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTP(S) website; private networks, credentials, and unusual ports are rejected. | |
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| scope | No | |
| errors | No | |
| status | Yes | |
| message | No | |
| signals | No | |
| next_step | No | |
| miss_count | No | |
| measurement | No | |
| not_measured | No | |
| score_percent | No | |
| checked_origin | No | |
| measured_at_utc | No | |
| unchecked_count | No | |
| coverage_percent | No | |
| external_data_policy | No | |
| separate_live_measurement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds useful scope context ('bounded' measurements, the experimental llms.txt signal, and what it explicitly does not measure) but says nothing about auth requirements, rate limits, or cost/latency of the checks.
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 the usage condition, then scope, then exclusions. Every sentence carries distinct information and nothing is repeated from the title or 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?
An output schema exists, so return values need not be explained, and annotations cover the safety contract. The scope statement plus the exclusion list make the tool callable without ambiguity; only minor operational details (rate limits, failure modes on rejected URLs) are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters carry their own descriptions (URL constraints, language enum with default), so the baseline of 3 applies. The description adds no syntax, format, or interpretation guidance for url or language beyond what the schema already states.
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 action ('measures') and enumerates the exact resource surface: page, robots, structured-data, sitemap, and experimental llms.txt signals. The negative list (AI mentions, rank, visibility, firewall passage, sales) further sharpens the boundary so an agent cannot confuse it with a ranking or visibility 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?
It gives an explicit trigger ('Use only when a user asks to inspect a public website') and clear exclusions that tell the agent when this tool is the wrong choice. It does not name a specific alternative tool to route to, but the sibling set is a catalog family, not a direct substitute, so the exclusion list carries the routing intent.
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.
advisors_catalog_get_service1 field changedOutput schema / $defs / PackageOutput / properties / price_statusAdded value: +{
+ "anyOf": [
+ {
+ "const": "pending_approval",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price Status"
+}advisors_catalog_list_services1 field changedOutput schema / $defs / PackageOutput / properties / price_statusAdded value: +{
+ "anyOf": [
+ {
+ "const": "pending_approval",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price Status"
+}advisors_catalog_match_service1 field changedOutput schema / $defs / PackageOutput / properties / price_statusAdded value: +{
+ "anyOf": [
+ {
+ "const": "pending_approval",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price Status"
+}advisors_order_prepare_link1 field changedOutput schema / $defs / PackageOutput / properties / price_statusAdded value: +{
+ "anyOf": [
+ {
+ "const": "pending_approval",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price Status"
+}advisors_site_check_basics1 field changedOutput schema / $defs / PackageOutput / properties / price_statusAdded value: +{
+ "anyOf": [
+ {
+ "const": "pending_approval",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Price Status"
+}advisors_catalog_get_serviceadvisors_catalog_list_servicesadvisors_catalog_match_serviceadvisors_order_prepare_linkadvisors_site_check_basicsDescribe a problem in plain language; get matching products with honest caveats. Never sponsored.
Match API, CSV, freight, analytics, and content needs to fixed-price services with authority gates.
Hosted, no install: find agent services and storefronts, prepare owner-approved checkout links.
Book a local business by saying what you need; matching businesses bid and you confirm one.
Add one secure layer between your agents and this server.