Mador checks whether AI assistants name your business. Read-only tools for your Mador account: results, competitors named, questions measured, pages and to-dos.
Scored across 7 tools
Each tool targets a distinct resource or view: projects, status, competitors, mentions, questions, pages, and todos. While get_status and get_mentions both involve assistant naming, status is aggregated and mentions is per-question, so boundaries are clear.
All tools follow a consistent snake_case verb_noun pattern: six get_* and one list_* prefix. No mixing of conventions.
Seven tools is well-scoped for a read-only analytics/reporting server. Each tool covers a distinct aspect of the domain without redundancy.
The surface covers read queries for projects, status, competitors, mentions, questions, pages, and todos comprehensively. However, there are no create, update, or delete operations (e.g., marking todos done, approving pages, adding questions), leaving lifecycle actions as dead ends for an agent.
The other businesses the assistants name most often for the same zone and category in the latest measurement, with the number of answers and questions for each, next to the project's own numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and determinism are covered. The description adds useful context the annotations do not: results are tied to 'the latest measurement' (a snapshot rather than live data) and are scoped to a zone and category. It does not disclose how zone/category are resolved, any rate limits, or pagination 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?
One dense sentence with the resource front-loaded and no filler. It is longer than strictly necessary but every clause (competitor set, scope, counts, comparison baseline) contributes 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 return-value burden and does so reasonably: competitor names, per-competitor answer and question counts, and the project's own numbers for comparison. Combined with annotations covering the safety profile and a fully documented single parameter, this is nearly complete, though it never explains what defines the 'zone and category' or the meaning of 'latest measurement'.
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 optional project_id parameter with 100% schema description coverage (including the 'optional when the account has exactly one project' rule), so the schema does the heavy lifting. The description adds nothing about the parameter, 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?
The description names the specific resource it returns (other businesses named most often by assistants) and the comparison scope (same zone and category, latest measurement, alongside the project's own numbers). It is easily distinguished from sibling get_mentions because it aggregates competitors and includes per-competitor answer/question counts. It lacks an explicit verb, but the resource and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no routing to alternatives such as get_mentions or get_questions, which return related raw data. The only usage signal is implicit: the phrase 'for the same zone and category in the latest measurement' hints at the context in which results are meaningful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For each measured question, which assistants name the business and which do not, and which other businesses they name instead. The project itself is marked with is_you.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds behavioral value only by explaining the returned structure, notably the is_you marker identifying the caller's own project — useful but modest beyond the 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?
One dense sentence with the scope ('for each measured question') front-loaded and zero filler. It is efficient, though the run-on clause structure takes slight re-reading to parse.
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-shape burden and does so adequately: per-question grouping, named/unnamed assistants, alternative businesses, and the is_you marker. Pagination or response format are not covered, but for a simple read-only lookup this is close to 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 description coverage is 100%, so the single project_id parameter is fully documented in the schema, including its optionality and the list_projects source. The description adds no additional parameter meaning, making the baseline 3 appropriate when the schema does the work.
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 concrete verb-and-resource picture: per measured question, which assistants name the business vs. which do not, plus competitor names, with the caller's project flagged by is_you. An agent can understand what it returns. However, it never names the sibling get_competitors, so the boundary between this and the competitor-listing tool must be inferred from wording alone.
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 explicit when-to-use, when-not-to-use, or alternative tool named. The phrase 'for each measured question' faintly implies the project needs measured questions, but an agent gets no routing guidance among get_competitors, get_questions, or get_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The answer pages Mador wrote for this project, with their status (draft, published, published with edits not yet republished), the public link when published, and whether one is waiting for the customer's approval.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns credit beyond that by enumerating the returned state model (draft, published, published with edits not republished) and the approval-waiting flag, which the agent cannot learn from annotations or schema. It still omits pagination or ordering 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?
One dense sentence that front-loads the resource and then enumerates the returned facets without filler. Every clause carries information the caller needs.
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 does much of the return-shape work by naming the fields returned, and annotations cover safety. Gaps are minor: no hint about pagination, ordering, or whether users can scope beyond the current project.
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 single project_id parameter and its list_projects sourcing are fully documented in the schema. The description adds nothing about the parameter, which is the expected baseline when the schema does the work.
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?
Identifies a specific resource (Mador's answer pages), the scope (this project), and the facets returned (status, public link, approval state). It reads clearly against siblings like get_competitors, get_mentions, and get_questions, though the retrieval verb ('get/list') is left implicit.
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 explicit when-to-use statement, no exclusions, and no named alternative. An agent can infer it is project-scoped page data, but nothing in the description tells it when this tool is the right choice versus get_status or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The questions Mador asks the assistants for this project: the zone questions shared by the category, and the free questions chosen by the customer, each with how often the business is named.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results carry a frequency-of-naming metric and split into zone vs free questions, which is useful return-content context given there is no output schema. It says nothing about ordering, pagination, or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler, front-loading the resource before the two sub-categories and the metric. It is slightly jargon-heavy ('Mador', 'zone questions') but every clause carries 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?
For a one-optional-parameter read tool with full annotation coverage and no output schema, the description covers the resource and the shape of what comes back. The main gap is the absence of any usage routing against the sibling read tools, which is minor for such a simple 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 description coverage is 100% and the single project_id parameter is fully documented in the schema, including its origin (list_projects) and its optionality for single-project accounts. The description adds no parameter-level information, which is acceptable at this coverage level.
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 identifies the resource precisely: the questions Mador asks assistants for a project, broken into zone questions and customer-chosen free questions, each annotated with business-naming frequency. That is specific enough to distinguish it from get_competitors, get_mentions, or get_todos. It lacks an explicit verb ('returns'/'lists') and doesn't name a sibling it is not, so it stops short of 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?
There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer from the resource name alone that this is the read path for project questions. Nothing routes it against get_mentions or get_competitors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest measurement of one project in plain words: how many assistants name the business out of the 12 (Monitor) or 14 (Growth) in the plan, in how many answers, assistant by assistant, and what changed since the previous measurement. Use it to answer «how am I doing on Mador?».
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds scope detail (latest measurement only, includes change vs. previous measurement, tied to a plan tier), but says nothing about auth requirements, latency, or the shape/format of the response beyond listing the metrics.
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 what the measurement contains and finished with the question it answers. The tier parentheticals are informative rather than filler, though the first sentence is dense with clauses and could be split.
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?
There is no output schema, so the description must carry the return-value burden, and it does: it enumerates the counts, the per-assistant breakdown, and the delta versus the previous measurement. Combined with annotations covering the safety profile and a fully documented single parameter, an agent has enough to call and interpret 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 description coverage is 100% for the single project_id parameter, including the note that it is optional when the account has one project. The description only implies a single-project scope ("one project") and adds no syntax or defaulting detail beyond the schema, 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?
The description names a concrete resource (the latest measurement of one project) and enumerates exactly what it reports: how many assistants name the business out of the 12 (Monitor) or 14 (Growth) targets, in how many answers, per assistant, plus the delta since the prior measurement. That is far more specific than a tautology, though it is phrased as a noun phrase rather than a verb+resource and never names which sibling it replaces.
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 usage cue — "Use it to answer «how am I doing on Mador?»" — which tells the agent the question this tool answers. There are no exclusions or named alternatives (e.g. get_mentions, get_competitors), so routing between siblings is still left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The open to-dos Mador suggests for this project this week, most useful first, and whether each is done inside or outside Mador. Growth plan only; on other plans it says so.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project id from list_projects. Optional when the account has exactly one project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, and closed-world behavior, so safety is covered. The description adds value beyond them: the result ordering, the inside/outside Mador classification, and especially the plan gating that changes behavior (Growth plan only). It omits return format/pagination detail, but that is minor for a simple list.
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 compact sentence that front-loads the resource and scope, with the ordering and plan caveat following. It is efficient overall, though the inside/outside Mador clause is slightly padded and could be implicit in the results.
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 read-only, single-parameter list tool with no output schema, the description covers what is returned (open to-dos, ordered, with inside/outside classification) and the plan-gating behavior. It is largely self-sufficient; only edge cases like empty results or scope of 'this week' are left undefined.
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 project_id parameter is already fully documented, including its optionality when the account has one project. The description only implicitly references 'this project' and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (open to-dos Mador suggests for this project this week), the ordering (most useful first), and an extra dimension (done inside or outside Mador). It is clear and specific, but it never explicitly distinguishes itself from siblings — though the resource itself (to-dos vs competitors/mentions/pages/questions/status) is inherently unambiguous.
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 a real usage constraint — 'Growth plan only; on other plans it says so' — which tells the agent the tool behaves differently by plan. However, there is no guidance on when to prefer this over alternatives or any prerequisites for the call itself; usage is implied by the resource rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the businesses (projects) this Mador account measures: name, zone, category, plan and the date and result of the latest measurement. Call this first to get the project_id used by the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile needs no restating. The description adds real behavioral value by disclosing that it returns the account's own measured projects plus the latest measurement result, but says nothing about result size, pagination, or empty-account 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 sentences, both earning their place: the first defines scope and return content, the second front-loads the sequencing instruction. No filler, no restatement of the title or annotations.
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 present, the description compensates by naming the returned fields and the fact that the latest measurement's date and result are included. Combined with the annotations covering the safety profile and zero parameters, an agent has everything needed to call and interpret this 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?
The tool takes zero parameters, so per the baseline there is no parameter semantics burden to carry. The description correctly implies a no-argument call and instead spends its words on scope and return fields.
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 ('Lists the businesses (projects)...') and enumerates exactly what is returned: name, zone, category, plan, and latest measurement date/result. It is clearly distinguishable from every sibling tool (get_competitors, get_mentions, get_pages, get_questions, get_status, get_todos), which all operate on sub-resources of a project.
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?
'Call this first to get the project_id used by the other tools' gives explicit sequencing guidance that tells the agent when this tool must run relative to siblings. It stops short of naming an alternative or a when-not condition, but the sibling set has no overlapping purpose, so no routing ambiguity remains.
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_competitorsget_mentionsget_pagesget_questionsget_statusget_todoslist_projectsSee how often AI answers name and link your brand, which rivals they name and which sites they cite.
Track brand visibility in ChatGPT, Gemini and Google AI answers: competitors, cited sources, checks.
Your website analytics as read-only tools: traffic, pages, errors, speed and AI-assistant visits.
Track how AI assistants talk about your brand and market, and learn how to show up better.
Add one secure layer between your agents and this server.
