Find who links to your competitors but not you, judge each opening, and draft the pitch.
Find pages that link to the named competitors but not to you, classified by whether a link is realistically winnable and why. Competitors are excluded from their own results: a competitor is never a prospect.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| competitors | No | Up to five competitor domains. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it adds useful behavior: results are classified by winnability and rationale, and competitors are explicitly excluded from their own results. The read-only nature is implied by 'Find', though side effects, auth, and rate limits are not addressed.
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 tightly worded sentences front-load the core function and then add an important edge-case rule. No filler or redundancy; every clause contributes meaning.
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 two simple parameters, the main invocation is inferable, and the winnability classification gives some sense of return content. However, with no output schema, the description does not specify the output shape or define 'realistically winnable', and it omits usage context relative to sibling tools.
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 50%: only competitors has a schema description, and the description maps 'you' to the domain parameter. It clarifies that competitors are the source of gap analysis, but it adds no format, example, or requirement details for domain beyond what the schema already provides.
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?
Description uses a specific verb ('Find') and names the exact resource: pages linking to competitors but not to the user's domain. It also describes the unique output classification (winnable and why), which separates it from siblings like discover_competitors and find_prospects.
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?
No guidance is given on when to use this tool versus alternatives such as discover_competitors or find_prospects. The description implies a backlink-gap use case but never states prerequisites, exclusions, or which sibling to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What one agent does, step by step, and what it needs: the values you must pass to run_agent, what it hands back, how many of its steps reach a vendor that charges, and anything currently stopping it from running.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | From list_agents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses useful behavioral content: step-by-step behavior, returned data, billed vendor steps, and current blockers. However, it does not explicitly state side effects (e.g., whether this tool is read-only or can trigger agent execution), which is a meaningful gap for an agent inspection 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?
All information is packed into one front-loaded sentence, with the primary purpose first and supporting output details after. It is somewhat dense, but every clause adds 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?
For a single-parameter, no-output-schema tool, the description covers purpose, needed input, expected return content, cost-relevant steps, and run blockers. It only lacks explicit usage direction and side-effect clarification.
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 schema already documents agent_id as 'From list_agents,' and the description adds the context that these are values needed for run_agent. That is helpful but not substantial; with 100% schema coverage the baseline of 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?
The description names the resource ('one agent') and the specific behavior ('what it does, step by step, and what it needs'), with concrete output categories. It is clearly distinct from siblings like list_agents (all agents) and run_agent (executes the agent).
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 implies a pre-run inspection use case by mentioning 'the values you must pass to run_agent' and blockers, but it never explicitly says when to prefer describe_agent over list_agents or run_agent. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the domains competing with this one, from both search results and link profile overlap. Returns each candidate with the evidence for it, so a wrong suggestion can be recognised rather than trusted.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| keywords | No | Optional. Sharpens the search half. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It clearly says results include evidence for each candidate and warns that wrong suggestions can be recognized rather than blindly trusted. This goes beyond the schema and gives agents a useful expectation of output quality and intent.
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 tight sentences with no filler. The core purpose is front-loaded, and the second sentence adds return-value context that helps the agent interpret results. Every phrase 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?
The tool has only two simple parameters and no output schema, so the description covers the essential contract: what gets discovered, from which signals, and that candidates come with evidence. It could say a bit more about what evidence looks like, but it is sufficient for safe invocation.
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 50%: the keywords parameter is described there and in the tool description, but the domain parameter is only implied by 'this one'. The phrase 'sharpens the search half' adds meaningful context for keywords, but the main domain parameter still relies on inference from the tool name.
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 verb ('Find') and a clear resource ('domains competing with this one'), and it specifies the two methods used ('search results and link profile overlap'). This distinguishes competitor discovery from sibling tools like find_prospects or backlink_gap without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by framing it around competitor overlap and evidence, but it does not explicitly state when not to use it or name alternatives. A note that this is for competitor discovery rather than prospecting, qualification, or gap analysis would improve routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write one outreach email for one prospect, in your own words, using the reason that prospect would link to you. It returns the subject and body and sends nothing: sending happens from your own mailbox, after you have read it. Requires a paid Mentionry plan.
| Name | Required | Description | Default |
|---|---|---|---|
| hook | Yes | Why this page would link to you. | |
| page_title | No | ||
| description | No | What your site does. | |
| sender_name | No | ||
| sender_site | Yes | Your domain. | |
| prospect_url | Yes | The page you want the link on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that the tool returns the subject and body, performs no sending, and that sending happens later from the user's mailbox. This is important behavioral context that an agent needs before invoking the 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?
Three short, purposeful sentences: the action comes first, then the output and non-sending behavior, then the requirement. Every sentence earns its place and the structure is front-loaded.
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?
Since there is no output schema, the description correctly explains the return value (subject and body) and the non-sending behavior. It leaves 'page_title' and 'sender_name' semantically unexplained, but those are optional and the core invocation path is well-covered by the description and required parameters.
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 67%, so the schema already documents most parameters. The description reinforces the meaning of 'hook' as the reason the prospect would link and 'prospect_url' as the target page, but it adds no new meaning for the undocumented optional params 'page_title' and 'sender_name'. 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?
The description uses a specific verb ('Write') and clearly identifies the resource and result: one outreach email for one prospect, returned as subject and body. It is clearly distinguishable from sibling discovery and verification tools, despite not naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need to draft a single outreach email with a personalized reason. It also provides an important exclusion ('sends nothing') and a prerequisite ('paid Mentionry plan'), which helps the agent decide when and whether to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the open web for pages that would plausibly link to this site: resource pages, roundups, listicles and directories in its subject. Returns each with the reason it was kept.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional. Narrows the search to one theme. | |
| domain | Yes | ||
| audience | No | ||
| keywords | No | ||
| description | No | What the site does. Use read_site if you do not have one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool searches the open web and returns each kept result with a reason, which is useful. However, it does not mention result limits, latency, data-source caveats, or how the plausibility filtering works.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and result format are front-loaded, and every phrase contributes meaning: what it searches, what types of pages it targets, and what it returns.
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?
The tool has five parameters, no annotations, and no output schema, but the description only covers the general purpose and one output behavior. Optional parameter semantics and usage boundaries versus sibling tools are missing, making the definition incomplete for confident invocation beyond the required domain.
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 only 40%, and the description does little to compensate for the undocumented parameters. 'domain' maps to 'this site' and 'subject' loosely relates to topic/audience/keywords, but audience, keywords, and description are not explained at all, leaving their semantics unclear.
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 verb and resource: 'Search the open web for pages that would plausibly link to this site.' It further specifies the types of pages (resource pages, roundups, listicles, directories), which clearly differentiates it from siblings like discover_competitors or backlink_gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when you want link-building prospects for a given site. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling tools are mentioned, so the agent must infer the selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The agents on this account: what each is called, how many steps it has, whether it would run as it stands, and when it last changed. Call describe_agent next to learn what one needs before running it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does explain what the response includes, especially the useful 'whether it would run as it stands' readiness indicator. However, it does not explicitly state that the operation is read-only, nor does it mention permissions, rate limits, or response shape beyond field names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the tool's purpose and output fields, and the second sentence adds a concise, actionable next step. 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 zero-parameter list operation, the description covers the key returned fields and suggests the next logical call. It is sufficient for an agent to invoke the tool correctly, though it omits potential details like ordering, pagination, or exact output schema, which would matter if the response were complex.
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 no parameters, so there is nothing to document. The baseline of 4 applies because the description does not need to compensate for missing parameter guidance.
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 that the tool lists agents on the account and enumerates the returned attributes: name, step count, runnability, and last modification time. It is distinguishable from describe_agent by positioning that as a follow-up, but it does not explicitly contrast with other list tools such as list_connections or list_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete usage flow: call list_agents to get an overview, then call describe_agent to learn requirements before running an agent. It implies this tool is for surveying agents and checking run-readiness, though it does not state explicit exclusions or alternatives like run_agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which outside tools this account has connected, and what each one is allowed to do here. Call it before offering to file, post or draft anything, so you can say what is actually available instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains what the tool returns—connected external integrations and their allowed permissions—and implies a non-mutating lookup. It does not explicitly state read-only behavior, but nothing about the description suggests side effects.
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 carry the full message: what the tool does and when to call it. The core purpose is front-loaded, 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?
For a parameterless list tool with no output schema, the description sufficiently explains what the tool returns and when it should be used. It does not specify the exact response shape, but the agent knows enough to invoke 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?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds no parameter-related confusion, and the schema already documents the empty input contract.
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 identifies the resource ('outside tools this account has connected') and the implied listing/read action. The phrase 'outside tools' distinguishes it from sibling tools like list_agents and list_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: call before offering to file, post, or draft anything, so the agent can report what is actually available. It does not mention alternatives or when-not-to-use cases, so it stops just short of a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The documents your agents have produced: what each is called, which agent wrote it, how long it is and how many versions it has. Pass an id to read_document for the text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It states that the tool returns metadata only and not text, and that ids are meant for read_document. However, it leaves 'how long it is' ambiguous (characters, words, pages?) and says nothing about pagination, ordering, or limits, which is a noticeable gap for an unannotated 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?
Two sentences with no filler: the first states the main purpose with specific output fields, and the second provides a useful routing hint. The most important information is front-loaded, and every sentence contributes value.
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 no-parameter list tool without an output schema, the description covers the essential output fields and points to read_document for content retrieval. Minor omissions exist, such as the exact definition of 'length' and any list ordering/limits, but the tool is simple enough that an agent can invoke 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?
The input schema has zero parameters and schema description coverage is effectively 100%, so there is no parameter documentation burden. The description adds no parameter-specific info, but it clarifies the output id's role with read_document. The no-parameters case warrants the baseline score of 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 uses a specific verb ('list') and a clear resource ('documents your agents have produced') and enumerates the returned fields: name, author agent, length, and version count. It also differentiates from read_document by noting that text requires a separate call, making the tool's role unambiguous among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes text retrieval to read_document ('Pass an id to read_document for the text'), which tells the agent when not to use this tool. It implies the tool is for metadata overviews, though it doesn't explicitly state 'use this when you need document metadata.' The context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Judge whether a domain is worth running link building for at all, from live search data. Returns a verdict, the measured signals behind it, and the honest case against. This is the same free diagnostic the dashboard runs, and for a large share of sites the answer is that the niche has nothing to mine.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to judge, for example mentionry.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool uses live search data, returns a verdict with measured signals and the honest case against, and is the same free diagnostic as the dashboard. This gives a clear picture of the tool's behavior and output without relying on structured metadata.
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, each earning its place: the first states the core purpose, the second describes the output, and the third provides useful expectation-setting. No redundant or filler language is present.
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 diagnostic tool with no output schema, the description is complete. It covers the purpose, data source, output shape, and the likely outcome, giving an agent enough context to invoke the tool appropriately and interpret its result.
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 already fully documents the single parameter with a descriptive example ('mentionry.com'), so schema coverage is 100%. The description adds no additional parameter-level meaning, which keeps this at the baseline of 3.
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 specific verb and resource: 'Judge whether a domain is worth running link building for at all'. It clearly distinguishes the tool from sibling tools like find_prospects or backlink_gap by focusing on the qualification verdict rather than prospect discovery or gap analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use the tool—before investing in link building for a domain—and sets expectations by noting that many sites will not be worth pursuing. It does not explicitly name alternative sibling tools or state when not to use it, 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.
The text of one document your agent wrote, with the agent, the step and the values that run was given. Returns the newest version unless an older one is asked for.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No | 1 is the newest. Omit for the newest. | |
| document_id | Yes | From list_documents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses version resolution ('Returns the newest version unless an older one is asked for') and the returned payload components. It does not mention failure modes or permissions, but for a read operation this 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?
Two tight sentences front-load the core purpose and then add the version detail. Every clause contributes meaningful information with no redundant 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?
For a simple read tool with no output schema, the description sufficiently covers the returned content and versioning, and the schema fully documents parameters. Minor omissions such as not-found behavior keep it just short of 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 document_id and version are already explained. The description mostly restates the version behavior already in the schema and adds no significant new parameter-level meaning.
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 identifies the resource ('one document your agent wrote'), the kind of output (text plus agent, step, and values), and the version behavior. This differentiates it from siblings like list_documents and read_site.
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?
Usage is implied rather than explicit: an agent can infer this is for retrieving document content, but no alternatives or when-not-to-use conditions are named. There is no guidance distinguishing it from list_documents or other document-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a domain and return what we think it is about: a description, its audience, and the keywords it should be found for. This is the brief every other tool takes as input, so call it first when you do not already have one.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the result is an interpretation ('what we think it is about'), implicitly signals a read-only operation via 'Read', and specifies the returned components. It could add caveats about freshness or edge cases, but it is reasonably transparent for a simple read 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?
Two sentences, front-loaded with purpose and output, followed by usage guidance. Every sentence adds value and there is no redundant 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?
For a single-parameter tool with no output schema, the description covers the output shape, the read intent, and the workflow position. The main gap is parameter format guidance, but the overall context is sufficient for an agent to invoke the tool reasonably.
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 0%, so the description must compensate. It only restates the concept of 'domain' without specifying format, examples, or whether to include protocol/subdomains. The property name 'domain' already conveys the basic meaning, so the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read a domain') and defines the deliverable: a description, audience, and target keywords. It also frames this as the foundational brief for sibling tools, which distinguishes it from tools like qualify_domain or read_document.
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 when-to-use directive: 'call it first when you do not already have one.' This clearly tells an agent the tool produces the shared input needed by other tools, making the intended workflow unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's own answer-engine measurements over a window: how often each tracked brand appears in recorded answers (visibility), its share of all mentions (share of voice), its mean position, and the ranking against named competitors. Group by day for a trend, or by model, region, persona, prompt or topic to find where a brand is weak. This is the data behind the dashboard's Answer Engine Insights.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window length in days. Default 30. | |
| dimension | Yes | How to group. `day` for a trend over time; the others compare buckets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by framing the operation as reading 'recorded answers' and returning measurements, which implies a read-only, side-effect-free operation. It also discloses what the grouping options produce (trend versus bucket comparisons), exceeding the minimal safety disclosure expected.
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, each earning its place: the first lists the metrics, the second explains grouping choices, and the third gives dashboard context. The description is front-loaded with the core function and contains 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?
For a two-parameter read tool with no output schema, the description explains the return concept well by naming the metrics and grouping behavior. It doesn't specify the exact response shape or edge cases, but with simple parameters and no nested objects, that is 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 the baseline is 3. The description adds meaning by tying the dimension parameter to analytical intent ('find where a brand is weak') and explicitly mapping day to trend and the other dimensions to comparisons, going slightly beyond the schema's terse enum descriptions.
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 uses a specific verb 'read' and resource 'visibility' while enumerating exact metrics: visibility, share of voice, mean position, and competitor ranking. It clearly distinguishes this tool from sibling tools like read_document and discover_competitors by focusing on the account's own answer-engine measurements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating this is 'the data behind the dashboard's Answer Engine Insights' and gives explicit guidance on when to use each grouping: day for trends, and model/region/persona/prompt/topic for finding weak spots. It doesn't name when-not-to-use alternatives, but the context is strong and the sibling list shows no overlapping analytics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of your agents once and return what every step did, in order, with what it returned and how long it took. Pass its declared inputs as an object keyed by their key from describe_agent. Steps that reach a paid vendor are counted against your live-sweep allowance, one each.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | No | The agent's declared inputs, keyed by `key`. Values are strings. | |
| agent_id | Yes | From list_agents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does well by explaining the sequence and content of the return value ('what every step did, in order, with what it returned and how long it took') and by disclosing that paid-vendor steps consume allowance. It could mention potential real-world side effects of running an agent, but the provided details are substantial beyond the bare 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 dense sentences, each earning its place: the first defines the behavior and output, the second tells the agent how to structure invocation, and the third discloses the cost implication. 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 two-parameter tool with no output schema, the description covers the high-level return shape, the input construction method, and a key consumer warning. It is almost complete, but lacks an explicit statement of what happens on failure or whether the run is synchronous, which would make it fully self-sufficient.
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. The description adds meaningful semantics for the inputs parameter by stating it must be an object keyed by the `key` values from describe_agent, which goes beyond the schema's generic 'keyed by key'. It does not add much about agent_id, but the schema already covers it with 'From list_agents.'
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 verb 'Run', the resource 'one of your agents', and the singular execution mode 'once'. It is immediately distinct from siblings like describe_agent, list_agents, and draft_pitch because it describes executing an agent and reporting the step-by-step results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage pointer: pass inputs keyed by their `key` from describe_agent, implying that describe_agent should be consulted first. It also flags a cost-related condition for paid vendor steps. It does not explicitly list when not to use the tool or name an alternative, but the execution purpose is clear enough in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a list of domains against your live backlink profile and report which of them now link to you, when the link first appeared, and whether it is still there. A link that was removed shows as a change rather than staying on the scoreboard.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Your domain. | |
| pitched | Yes | The domains or URLs you pitched. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explains the live-profile check, the reported fields, and the important nuance that removed links appear as changes rather than remaining on the scoreboard. It does not cover errors, rate limits, or propagation delays, but the core behavior is clearly disclosed.
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 dense sentences with no filler. The main action and output are front-loaded, and the second sentence adds a valuable behavioral detail that prevents misinterpretation of removed links.
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 tool with only two simple parameters and no output schema, the description provides everything an agent needs to invoke it correctly: what to supply, what the report contains, and how removed links are treated. No critical behavioral information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already fully documented. The description adds only marginal parameter-level context by framing 'pitched' as the domains to check and 'domain' as your own domain, which mostly restates the schema. 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?
The description states a specific action ('Check a list of domains against your live backlink profile') and clearly defines the output: which domains now link, when the link first appeared, and whether it is still present. It distinguishes itself from backlink-related siblings like backlink_gap by focusing on verifying previously pitched domains rather than finding gaps or prospects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its context: verifying whether pitched domains have landed links in the live backlink profile. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of the highest tier of usage guidance.
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. Dates show when Glama detected each change.
describe_agentlist_agentslist_connectionslist_documentsread_documentread_visibilityrun_agentbacklink_gapdiscover_competitorsdraft_pitchfind_prospectsqualify_domainread_siteverify_linksClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Find where ChatGPT names your competitor, write the page that closes the gap, measure it.
Find competitors, trace how they grew, watch what they ship — plus your Search Console.
Backlink Analysis MCP for AI Agents: authority, referring domains, and competitor link gaps.
Backlink & domain authority MCP for AI agents: referring domains, link gap, toxic review queue
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: agents, documents, prospects, competitors, visibility, and link checks are clearly separated. Even the closely related link-building tools are differentiated by whether they find prospects, find competitor gaps, or verify existing links.
Almost every tool follows a clear verb_noun pattern using lowercase snake_case, such as list_agents, run_agent, and verify_links. The one minor deviation is backlink_gap, which reads as a noun phrase rather than an imperative verb, so the pattern is not perfect.
Fourteen tools is within the ideal range and each tool covers a meaningful part of the Mentionry workflow. The count feels justified given the breadth of features: site analysis, competitor discovery, prospecting, link verification, outreach drafting, agent management, document retrieval, and visibility reporting.
The core workflow is well covered: audit a site, find competitors, discover prospects, verify links, draft outreach, run agents, and read results. The main gaps are agent lifecycle management and document management beyond reading, but those may reasonably live in the Mentionry dashboard rather than the MCP surface.
