Unilytics MCP Server

Official

by TeamUnilytics

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Several tools overlap in purpose: site_map and aeo_site_pages both discover site URLs; serp_results and aeo_serp_urls both fetch Google results; content_scrape, js_scrape, batch_scrape, and site_crawl have overlapping scraping functions; the many aeo_* tools are similarly named and hard to distinguish. Descriptions help some, but the boundaries between tools like aeo_cluster_by_urls vs aeo_cluster_prompts or kb_write_text vs kb_add_file are not immediately clear.
Naming Consistency2/5
Tool names mix consistent verb_noun patterns (list_skills, get_skill, create_skill) with prefixed groups (aeo_*, kb_*, seo_*) and standalone tools that deviate from the pattern (web_research_tool, page_screenshot, site_map, google_trends, social_profile). The prefixes are internally consistent, but the overall set has no single naming convention, making it harder to predict tool names.
Tool Count1/5
With 72 tools, the server has an extreme number of tools, far exceeding the 50+ threshold for a coherent set. While the scope is broad (SEO, content, ads, analytics, project management, skills, knowledge bases), the sheer volume makes it unwieldy and likely to confuse agents.
Completeness3/5
The tool surface covers a wide range of marketing and SEO operations, including skills CRUD, scraping, SERP analysis, ad libraries, analytics, and knowledge base management. However, there are notable gaps: projects have create but no update or delete, folders lack delete/update operations, and there is no way to remove tracked keywords, competitors, prompts, or locations. These missing lifecycle operations create dead ends for some workflows.
Average 4/5 across 72 of 72 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, indicating a safe read operation. The description adds useful context about conditional behavior: "If a URL is provided, also checks structured data (schema.org markup)" and clarifies the domain/URL scope. However, it does not disclose what a technical SEO audit entails or return format, so it only partially covers behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose, a conditional note, and a two-item argument list. No filler or redundancy. The structure is clear and front-loaded, though the Args section could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return values or audit scope, but it does not. The config parameter remains unexplained, and there's no detail on what 'technical SEO audit' includes. The core behavior is covered, but these gaps make it incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does document domain and url in the Args section with examples and purpose, but the third parameter 'config' is completely absent from both the schema and the description. Partial compensation limits the score to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Run a technical SEO audit on a domain or specific URL." This clearly distinguishes the tool's core purpose. The mention of checking structured data with a URL adds further specificity, though no sibling tool is explicitly named for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 similar alternatives such as on_page_audit, site_crawl, or seo_domain_overview. The only conditional guidance is that providing a URL also checks structured data, but there are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable context about cost/performance ('expensive multi-API pipeline') and the return shape ('{volume, bucket}'), going beyond annotation basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the purpose stated first and the return value second. No redundant words or filler—every part contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers its core purpose and output format. However, missing parameter explanations and usage context make it only partially complete for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for unclear parameters. It only references 'prompt' implicitly; 'topic' and 'config' remain unexplained, with no hints about their format or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'AI search-volume estimate for a prompt', which is specific and identifies the resource (prompt) and action (estimate). It distinguishes from siblings by being the only volume-focused tool, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives is provided. The phrase 'expensive multi-API pipeline' implies cost sensitivity but does not offer selection criteria or compare with other AEO tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by disclosing that it combines Serpstat backlink overview with Moz domain authority data, which indicates data provenance. However, it does not mention output format, rate limits, or any caveats about data freshness or availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose and outputs, the second adds data-source context, and the Args block clarifies the required parameter. Only minor redundancy exists with the schema for the 'domain' parameter, but overall it is tightly written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one required parameter, no output schema), the description provides adequate purpose and data-source context. It lacks details on return structure, limitations, or when to prefer other SEO tools, but for a straightforward read-only analysis tool it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the responsibility. It explains the 'domain' parameter with a clear example ('example.com'), which is helpful. However, the 'config' parameter is entirely undocumented in both the schema and the description, leaving the agent without guidance on its purpose or accepted values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and a clear resource ('a domain's backlink profile'), and lists concrete metrics (referring domains, domain authority, spam score). It distinguishes itself from sibling SEO tools by focusing on backlink data and naming the combined data sources (Serpstat and Moz).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not provide any guidance on when to use it versus alternatives like competitor_analysis or seo_domain_overview. There are no exclusions, prerequisites, or contextual hints about suitable scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description is consistent. The description adds some behavioral context by specifying what is extracted (content, headings, structure) and that include_metadata controls meta/OpenGraph output, but it does not disclose limitations like JavaScript rendering, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, followed by a clear Args block. Every sentence provides relevant information; no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of several sibling scraping tools, the description is incomplete. It lacks guidance on tool selection, does not explain the return value structure (no output schema exists), and misses the config parameter, making it insufficient for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 provides useful explanations for 'url' (full URL with example) and 'include_metadata' (meta tags and OpenGraph data), but completely omits the 'config' parameter, which remains undefined in both the schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the action ('Scrape a web page') and the resource, and specifies the extraction outputs ('content, headings, and structure'). This distinguishes it from siblings like js_scrape (JavaScript rendering) and batch_scrape (multiple pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as js_scrape, batch_scrape, or site_crawl. It does not mention limitations (e.g., dynamic content) or appropriate scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description's 'List' is consistent. The description adds the alias 'Contexts' and scoping to a project, but does not disclose pagination, return format, or other behavioral details. With annotations present, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The Args section is structured but could be cleaner (e.g., bullet points). Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is mostly adequate. The key parameter is explained, but the optional config parameter is ignored, and the return values are not described. Given the tool's simplicity and the presence of a similarly named sibling, a bit more detail would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the required parameter project_id as 'The project UUID (from list_projects),' which adds meaningful provenance and type hints. However, the optional 'config' parameter is not described, and with schema description coverage at 0%, the description must compensate but only covers half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List the folders (Contexts) in a project' with a specific verb and resource. The scope is defined by 'in a project,' which adds clarity. However, it does not explicitly distinguish itself from the similarly named sibling tool 'list_folder,' so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite by stating 'project_id: The project UUID (from list_projects),' which guides the user to call list_projects first. However, it does not mention when to use this tool over alternatives or any exclusions, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds behavioral context by promising 'intent-balanced' and 'deduped' outputs. It does not disclose return format or limits, but the added qualifiers go beyond the basic read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence: it leads with the core action and resource, then adds two compact behavioral qualifiers. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns, but it does not. It also omits parameter behavior and usage context for a tool with six parameters, leaving it meaningfully underspecified despite the read-only annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it barely does. It only implies 'topic' and hints at existing_prompts via 'additional' and 'deduped'; brand, config, target_count, and primary_intent are left unexplained for a six-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Propose') and resource ('additional natural-language AEO prompts') with a clear scope ('for a topic'). The qualifiers 'intent-balanced + deduped' distinguish it from sibling tools like aeo_filter_prompts or aeo_cluster_prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as aeo_cluster_prompts or aeo_filter_prompts. There are no prerequisites, exclusions, or use-case statements; the only implied use is 'generate prompts,' which is insufficient for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, so the description doesn't need to state read-only behavior. It adds context about the return values (age, gender, parental status, income tiers), but does not explain how the optional 'config' parameter affects behavior or disclose any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and followed by a concise list of return types. No unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one optional parameter and no output schema. The description adequately covers what data is returned and the intended context. The only gap is the undocumented 'config' parameter, which is a minor omission for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one 'config' parameter with no documentation (0% schema description coverage), and the description does not mention it at all. With coverage this low, the description must compensate, but it leaves the parameter completely unexplained, providing no guidance on what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('all available Google Ads demographic targeting options'). It also lists the exact categories returned (age ranges, genders, parental status, household income), distinguishing it from sibling tools like keyword_planner or audience_segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'useful for building campaign targeting criteria,' providing a clear use case. However, it does not explicitly compare this tool to alternatives such as audience_segments or audience_recommendations, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint: true already indicating a safe read operation, the description adds no further behavioral context. It does not mention limitations of Google Trends data (e.g., relative vs. absolute values, sampling), nor what the output looks like. The description effectively stops at stating the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear one-sentence purpose followed by a brief Args section. Every line provides useful information: examples for keywords and enumerated options for time_range. No fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and read-only annotation, the description is mostly adequate. However, it fails to explain the 'config' parameter, does not describe the return format (especially since there is no output schema), and omits any caveats about Google Trends data. These gaps make the tool less predictable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, so the description must compensate. It does explain 'keywords' with an example and lists all valid values for 'time_range'. However, the 'config' parameter is completely undocumented, and no explanation is given for why it exists or how it might affect behavior. Coverage is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Compare keyword interest over time') and resource ('Google Trends data'). This distinguishes it from sibling tools like keyword_research or keyword_rankings, which focus on different data sources or metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to compare keyword interest over time. However, it does not explicitly mention alternative tools or provide any 'when not to use' guidance. The intended use is clear enough from context, but no exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is known. The description adds that results are 'synthesized findings' but does not disclose rate limits, source attribution, or whether external links are returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. The Args section is concise, includes a useful example, and avoids redundant filler. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify return structure, but it only vaguely says 'synthesized findings.' The config parameter is unexplained, and research_type options lack elaboration. Adequate for a simple tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description manually documents query (with an example) and research_type (with allowed values). However, the config parameter is completely undocumented, and research_type values are not explained. Partial compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Research a topic using AI-powered web search' and mentions it returns synthesized findings. This distinguishes it from more specialized siblings like keyword_research or competitor_analysis, though it could be more explicit about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies generic use for web research topics, but does not explicitly state when to choose this over sibling tools like serp_results or content_scrape. The research_type parameter offers some guidance on subtypes, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation. The description adds value by mentioning text embedding similarity and the return shape, but does not disclose potential caveats such as input size limits, API costs, or how 'clusters' are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then provides compact input and output contracts. No wasted words; every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description does mention return keys ({clusters, n_items, n_clusters}) but does not describe the structure of each cluster. It also omits semantics for three optional parameters. It is adequate for a simple clustering operation but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does explain the structure of 'items' with id/text/intent?/volume?, which is helpful, but leaves 'brand', 'config', and 'distance_threshold' undocumented. The distance_threshold parameter is especially important and receives no explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Group'), the resource ('prompts'), and the method ('by text embedding similarity'). It distinguishes from sibling tools such as aeo_cluster_by_urls by explicitly targeting prompts rather than URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you need to cluster prompts by topic. However, there is no explicit guidance on when to use this over alternatives like aeo_filter_prompts or aeo_cluster_by_urls, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no read-only or destructive hints, so the description must disclose behavior. It explains what a folder conceptually is but omits effects like whether creation is idempotent, what happens on duplicate names, what the API returns, or permission requirements. The write nature is implied by 'create' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the clear purpose. The conceptual explanation about folder grouping adds context without excessive verbosity. The args section is cleanly formatted, though the inclusion of the 'content refresh' example twice could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 3 parameters and no output schema, the description covers the core mechanics but misses the config parameter and any mention of return values or error conditions. It is adequate for basic use but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains project_id and name clearly, including source for project_id and an example folder name. However, the optional 'config' parameter is not described at all, and with 0% schema coverage, this leaves a gap in understanding the full parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a folder (Context) within a project to organize skills and files, distinguishing it from project-level tools by describing the grouping purpose. The verb 'create' and resource 'folder' are specific and align with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite: 'Call list_projects() first for the project_id.' It also explains when a folder is useful (to group related skills and files). However, it does not explicitly mention alternatives or when not to use it, such as when adding to an existing folder (add_skill_to_folder).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds return detail (file counts + sizes). However, it does not disclose potential limitations like pagination or the role of config, so behavioral transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, resource, and output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, the description covers the core purpose and output, but the unexplained `config` parameter and lack of alternative guidance leave gaps. Given the absence of output schema, it's adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions project_id implicitly. The optional `config` parameter is entirely unexplained, leaving the agent to guess its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a project's Knowledge Bases (collections) with file counts and sizes, using a specific verb and resource. It distinguishes itself from sibling kb_* tools by focusing on listing with summary metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like kb_search or kb_get_status. The context of listing collections is implied, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds that the tool returns monthly search volumes, competition level, and trends, and that it uses the official Google Ads API. It does not discuss rate limits, auth requirements, or failure modes, which would be richer context. With annotations covering the read-only nature, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence summary followed by a short elaboration and parameter documentation. Every sentence adds value, and the key information is front-loaded in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description explains the return fields (monthly search volumes, competition, trends) and the input semantics for the required parameter. The main gaps are the undocumented 'config' parameter and the lack of usage limitations, but given the annotations and simplicity, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The Args section defines the 'keywords' parameter with a concrete example, but the optional 'config' parameter is left undocumented. This partially fills the gap but not completely, so it falls below the baseline 4 for full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generate keyword ideas with search volume from Google Ads Keyword Planner' with a specific verb and resource, and elaborates that it returns related keywords with search volumes, competition, and trends. It does not explicitly differentiate from sibling tools like keyword_research or google_ads_data, so it misses the sibling differentiation needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it uses the official Google Ads API and takes seed keywords to generate ideas. However, it does not state when to use it over alternatives such as keyword_research or google_ads_data, nor any exclusions or prerequisites. Therefore, usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds context about organic search scope and overlap metrics. However, it does not disclose additional behavioral traits such as result limits, data freshness, or any side effects beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, followed by a short parameter list. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the readOnly annotation helps, but the missing 'config' parameter, vague 'overlap metrics', and lack of output description leave gaps. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains 'domain' and 'country' with examples, but omits the 'config' parameter entirely and gives no detail on what 'overlap metrics' means in the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds a domain's organic search competitors and their overlap metrics, using a specific verb and resource. This distinguishes it from siblings like competitor_ads by specifying 'organic search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (competitive analysis) but does not explicitly explain when to use this over other SEO tools or mention alternatives. No exclusions or preconditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is a soft delete (archive) and that built-in skills cannot be deleted, which are important behavioral traits. However, it does not mention permissions, reversibility, side effects, or failure modes, and annotations offer no safety hints, so the description only partially covers the needed transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded with the main action, and uses a clear Args section. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the undocumented config parameter is a notable gap. The description covers the core deletion behavior and skill_id format, but does not explain config or expected outcomes, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to skill_id by specifying its format (user/... or project/...), which is not present in the schema. However, the optional config parameter is completely ignored, leaving one of two parameters without any explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (archive/soft delete) and the resource (editable skill), and explicitly notes that built-in skills cannot be deleted. This distinguishes it from sibling tools like get_skill or read_skill_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context by restricting use to editable skills and excluding built-in skills, but it does not explicitly name alternative tools or explain when to use this over others. Usage guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, so the read-only nature is covered. The description adds context about credit costs for other tools, but does not disclose additional behavioral traits of this tool itself, such as whether the balance check consumes credits or how usage is reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core purpose, and the second provides actionable guidance with cost context. Every sentence earns its place with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the main aspects: what it does and when to call it. However, it omits any explanation of the config parameter and does not clarify whether the balance check itself consumes credits, which are minor but notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'config' with no description and schema coverage is 0%. The description does not mention this parameter at all, leaving the agent without any explanation of its purpose or how to set it. The description fails to compensate for the lack of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check your Unilytics credit balance and API usage' with a specific verb and resource. The title 'Check Credit Balance' reinforces the purpose, and it uniquely distinguishes this tool from the many siblings that perform data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call before expensive workflows and provides cost information for data tool calls, noting that discovery tools are free. This gives clear usage context and a when-not (for free tools), though there is no direct alternative tool to compare with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so safety is clear. The description adds behavioral value by disclosing that the result is a catalog grouped by category, and lists the categories. It does not mention the optional config parameter, but the read-only and list-oriented behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary function, and all sentences serve a purpose. The category list and get_skill() pointer are useful, though the phrase 'battle-tested, multi-step marketing workflows' is slightly promotional without adding operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, it communicates purpose, categories, and the logical next step. However, the unexplained config parameter and the lack of any output schema details mean an agent doesn't know the exact catalog structure or how config modifies the listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'config' with zero description and 0% schema description coverage. The description completely ignores this parameter, leaving agents with no guidance on what config accepts or how it affects the returned catalog.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all available Unilytics workflow skills', using a specific verb and resource. It clearly distinguishes itself from siblings by framing this as the discovery entry point and directing to get_skill() for the full recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: first list skills to get a catalog, then use get_skill() to load the full workflow recipe. It doesn't explicitly state when not to use it, but the explicit pointer to get_skill() and the category list provide practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that results include organic traffic, keyword count, and visibility, but does not discuss error behavior, rate limits, or data freshness. No contradiction exists between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single-sentence summary followed by an Args block. It is front-loaded with the tool's purpose and contains no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for basic invocation, naming key output metrics and required parameters. However, with no output schema and an unexplained 'config' parameter, it is not fully complete for an agent to confidently predict all behaviors and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains 'domain' with an example and 'country' with a default, but the 'config' parameter is completely undocumented, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get comprehensive SEO overview for a domain including organic traffic, keywords count, and visibility,' combining a specific verb with a resource and the expected output fields. This distinguishes it from sibling SEO tools like keyword_research or backlink_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a high-level domain overview, but it does not explicitly state when to prefer this over alternatives or mention exclusions. Sibling tools cover related but different scopes, yet no direct comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares a safe read operation; the description adds the 'organic traffic' scope and domain/country context. It does not contradict annotations, but it does not disclose output format, pagination, or data freshness, so it adds only moderate transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by a concise Args block. Every line adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and readOnlyHint annotation, the description is adequate, but no output schema exists and the return format is not described. It also omits any mention of the config parameter, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful context for 'domain' (with example) and 'country' (two-letter code, default 'us'), but it omits the 'config' parameter entirely. With 0% schema description coverage, the description partially compensates but remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb + resource: 'Get a domain's top-performing pages by organic traffic.' It defines the scope and differentiates from sibling tools like site_map or aeo_site_pages by emphasizing organic traffic performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it (to find top organic pages for a domain), and the domain/country parameters give clear context. However, it does not explicitly mention alternatives or exclusions, so the agent must infer usage from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by specifying the method (robots.txt) and the exact return structure. This is valuable since there is no output schema, though it does not cover failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous words. It is front-loaded with the core action and includes the return type efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers its main purpose, safety, and return format. However, the undocumented optional 'config' parameter creates ambiguity, preventing it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the 'config' parameter or the expected format for 'site'. While 'site' is inferable, the opaque 'config' leaves a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers a site's sitemaps via robots.txt, using a specific verb and resource. It also includes the return format, distinguishing its functionality from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when sitemap discovery is needed), but it does not explicitly mention alternatives or exclusions. Given the sibling tool 'site_map' exists, additional guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description builds on that by adding useful context: parallel processing, return content (markdown and metadata), the 10-URL limit, and the js_rendering behavior. It does not cover failure handling or rate limits, but given the annotations, the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by use cases, return info, and arguments. It is efficient, though it could be slightly more structured with bullet points for the Args section. Still, every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch scraping tool, the description covers the limit, parallel behavior, return format, and one toggle. But it omits the 'config' parameter entirely, says nothing about error handling or partial failures, and doesn't specify the result structure (e.g., keyed by URL). This leaves some gaps for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for 'urls' and 'js_rendering' by explaining their purpose and constraints. However, the 'config' parameter is completely undocumented in both the schema and description, leaving a gap for one of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scrape multiple URLs in a single call (up to 10 URLs).' It uses a specific verb and resource, and the 'much faster than scraping one by one' hints at differentiation from single-URL tools, though it doesn't explicitly name sibling tools like js_scrape or content_scrape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'competitor analysis, content gap analysis, SERP page comparisons, link prospecting, or any task requiring data from multiple pages.' This gives clear context for when to use the tool, but it doesn't include exclusions or explicit alternatives beyond implying single-page scraping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers safety, and the description adds that results include headlines, descriptions, and target keywords. However, it does not disclose other behaviors like pagination, rate limits, or error responses, which is acceptable given the simple read-only nature but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear purpose, followed by a compact argument list. Every sentence adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description gives a sufficient sense of result content (headlines, descriptions, keywords) and required inputs. The omission of the 'config' parameter and lack of error-handling details leave minor gaps, but overall it is fairly complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents 'domain' with an example and 'country' with a default, adding meaning beyond the schema. However, the 'config' parameter in the schema is completely undocumented, leaving a gap in parameter coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('competitor's Google Ads copy') with elaborated content (headlines, descriptions, target keywords), clearly distinguishing it from broader tools like competitor_analysis or google_ads_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving competitor ad copy but does not explicitly state when to prefer this over alternatives such as google_ads_transparency or competitor_analysis. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation, so the description does not need to repeat safety. The description adds useful context by naming the output areas (Core Web Vitals, performance score, opportunities), but it does not disclose behavioral traits like execution time, URL accessibility requirements, or rate limits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line summary followed by a clear Args block. Every sentence earns its place, and the most important information is front-loaded. No unnecessary verbosity or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only audit tool, the description covers the key purpose, primary parameters, and expected output categories. Since there is no output schema, the description's mention of Core Web Vitals, performance score, and opportunities provides sufficient completeness for an agent to select and invoke the tool. It does not delve into detailed return formatting, but that is not essential for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must carry the burden. It clearly explains 'url' (full URL to audit) and 'strategy' (desktop or mobile with default), adding value over the bare schema. However, the 'config' parameter is not mentioned at all, leaving its purpose and format undocumented. This gap prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits a page's loading performance with a specific verb ('Audit') and resource ('page's loading performance'), and lists distinct output categories (Core Web Vitals, performance score, opportunities). This differentiates it from sibling SEO audit tools like technical_seo_audit or on_page_audit, which focus on broader SEO factors rather than page speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to evaluate page loading performance), but it does not explicitly state when to use it over alternatives or mention any exclusions. No direct comparison to sibling tools such as on_page_audit or site_crawl is provided, leaving the agent to infer appropriate usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds useful context about returning top 20 organic results and the location_code default, but doesn't disclose response format, pagination, or any rate limits. This aligns with the annotation, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, opening with a clear purpose statement followed by a brief Args list. Every sentence provides necessary information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with annotations and default parameters, the description covers the essential aspects: what it does, key arguments, and defaults. The lack of an output schema is acceptable, but the unexplained 'config' parameter and absence of any note about result format keep it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description clarifies keyword (with example) and location_code (Google Ads location code with default). However, the 'config' parameter is left entirely unexplained, and no description is given for the return value format. The description partially compensates for the schema gap but omits one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specific resource: 'current Google search results for a keyword (top 20 organic results).' It also narrows the scope to top 20 organic results, distinguishing it from broader tools like web_research_tool or keyword_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving live Google organic results for a keyword, but does not explicitly state when to use this tool versus alternatives like web_research_tool or keyword_research. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so the read-only nature is already declared. The description adds that it is 'fast' and 'without scraping content,' which is useful context, but it does not reveal output format, limits, pagination, or error behavior. The added behavioral detail is minimal and does not go significantly 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear one-sentence summary, then provides a brief list of use cases, followed by an Args section. Every sentence is purposeful and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only URL discovery tool, the description covers the core purpose and main use cases. However, gaps remain: the 'config' parameter is unexplained, and there is no mention of the return format or any limits. This leaves some ambiguity for an agent deciding how to invoke the tool and interpret its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter semantics. It explains 'url' with an example, but the optional 'config' parameter is completely undocumented. With 1 of 2 parameters unaddressed, the description does not adequately compensate for the missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Discover all URLs on a website without scraping their content.' This uses a specific verb ('Discover') and resource ('URLs on a website'), and explicitly distinguishes it from content-scraping tools by noting it does not scrape content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific use cases: 'sitemap audits... finding unindexed pages... understanding site architecture, or scoping a crawl before running it.' This gives clear guidance on when to use the tool, but it does not explicitly name alternative tools or say 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations beyond the title, the description carries the transparency burden. It discloses that the operation appends to per-skill memory and never modifies the built-in skill body, which is key behavioral context. However, it does not mention idempotency, permissions, or response behavior, which would make it more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief purpose statement, a usage paragraph, and an Args list. It is front-loaded and each sentence contributes value. Some redundancy exists (e.g., 'append it here' and 'Save a learning'), but overall it is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description provides essential context: the workflow (after skill completion, with user confirmation), the target (per-skill memory), and the two key params. The config parameter is unexplained, but since it's optional and has a default, the omission is minor. The tool is otherwise sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains skill_id ('The skill the learning belongs to') and text ('The learning/workaround/preference to remember') with useful detail. However, the 'config' parameter, though optional, is entirely unexplained, leaving a gap in the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save a learning to a skill's MEMORY — the self-learning loop.' It specifies the verb 'append' and the resource (skill memory), and distinguishes from siblings by noting it works for built-in skills without modifying the skill body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: after completing a skill, ask the user for confirmation, then append. It also clarifies that it works for built-in skills. However, it does not explicitly mention alternatives like get_skill_memory or compact_skill_memory, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns by describing a read-only retrieval of guidance. It adds valuable context about the content (progressive disclosure, gotchas, measured-not-claimed gates, etc.) and notes the grounding in Claude Code's skill system, which goes beyond the annotation's simple safety hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with the key directive to read before create_skill. The second paragraph is dense but informative, listing the topics covered. Slightly long but each sentence earns its place; not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, content, and usage context well, but omits the meaning of the 'config' parameter and does not mention output format or that it requires no arguments. For a simple read-only guide with no output schema, this is a moderate gap, especially given the undocumented parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'config' with no description and 0% schema coverage. The description entirely fails to explain what 'config' is, whether it's needed, or what values it accepts, providing no compensation for the schema gap. This is a critical omission for an agent selecting or invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns skill-authoring best practices and a SKILL.md template, and explicitly positions it as a prerequisite for create_skill. This distinguishes it from sibling tools like get_skill or read_skill_file, and the verb is specific ('Returns').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to read this 'BEFORE authoring a new skill with create_skill' and says to 'Call this when the user asks you to create, port, or refactor a skill.' This provides clear when-to-use guidance and implicitly contrasts with create_skill and other mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true; the description adds that it queries multiple AI models with the same prompt and analyzes brand mentions. It does not disclose return format, behavior when brand is omitted, or potential costs/rate limits, so the added context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: opening summary, elaboration, usage note, and parameter list. Every sentence adds value without redundancy, and it is appropriately sized for a 3-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers core purpose and two main parameters but lacks output format description (no output schema exists) and does not explain the config parameter. Given the complexity of querying multiple AI models, these gaps make it incomplete for a robust understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 0%, the description compensates well for prompt and brand with clear explanations and examples. However, it entirely omits the config parameter, and the brand description ('track in responses') is somewhat vague, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks how a brand appears in AI-generated answers from ChatGPT, Claude, and Perplexity. It uses a specific verb ('Check') and defines the resource, distinguishing it from sibling SEO/AEO tools by focusing on brand mentions in AI responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this for Generative Engine Optimization (GEO) analysis,' providing a clear when-to-use context. However, it doesn't mention alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds useful behavioral context by specifying it returns full extracted content plus metadata, not just search chunks. However, it doesn't disclose error handling, auth requirements, or potential limitations. With annotations covering safety, the description adds some but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action and key differentiator ('full extracted content + metadata') front-loaded. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with readOnly annotations, the description covers the core return value, use cases, and differentiates from search. There is no output schema, but the description gives enough context for an agent to invoke it correctly. It could mention possible failure modes or the config parameter, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the parameters (project_id, document_id, config). It implies document_id refers to a known document but doesn't define it explicitly or mention the role of project_id. The description fails to compensate for the lack of schema-level parameter documentation, leaving the agent to rely on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a KB document's full extracted content and metadata, distinguishing it from search chunks. It also names specific use cases: pulling a known document into context or reading a previously-written artifact end-to-end. This is a specific verb+resource with clear differentiation from siblings like kb_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: when a full document is needed rather than search chunks, and for reading known artifacts end-to-end. It implicitly contrasts with kb_search by saying 'not just search chunks', though it doesn't explicitly name alternatives or state when not to use. This is clear guidance but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, covering the non-destructive nature. The description adds useful context about output fields (positions, volume, URLs) and pagination (50 results per page), but it does not disclose potential result caps, rate limits, or the fact that 'all keywords' is limited by pagination. There is a minor inconsistency between 'all' and pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a compact Args list. The purpose is front-loaded, and every line provides necessary information. There is no fluff or repetition of schema defaults without additional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and sparse annotations, so the description carries the burden. It covers the main output fields and pagination, but the 'config' parameter is ignored, the return structure is not described in detail, and the 'all keywords' phrase conflicts with pagination. More detail on response format and limitations would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains three of four parameters: domain (with example), country (two-letter code, default), and page (with results per page), adding practical meaning beyond the schema. However, the 'config' parameter is completely undocumented, which is a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get all keywords a domain ranks for with positions, volume, and URLs,' which uses a specific verb and resource. It clearly distinguishes from sibling tools like keyword_research (which likely focuses on discovering new keywords) and seo_domain_overview (which presents an overall summary).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit 'when to use' or 'use this instead of X' guidance. The description implies usage for checking a domain's existing keyword rankings, but it does not mention exclusions or alternatives among the many sibling SEO tools. This is acceptable but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds the specific on-page aspects audited, but doesn't disclose return format, config behavior, or any other traits. With annotations, 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus an args list, front-loaded with the main purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple, but the description omits what the audit returns and how config affects behavior. With no output schema, this is a notable gap. Annotations cover safety, but config remains opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates for the url parameter with format and example. However, the optional config parameter is entirely undocumented, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it audits a specific page's on-page SEO and lists specific elements (title, meta, headings, content quality). This distinguishes it from sibling audits like technical_seo_audit and page_speed_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for analyzing on-page SEO of a single URL, but doesn't explicitly state when to prefer it over technical_seo_audit or other audits. Provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include a title with no safety hints (readOnly/destructive). The description adds some behavioral context by specifying the required 'text' field and the expected object shape, and mentions that structured errors may be returned and that retrying is possible. However, it does not disclose side effects like deduplication, overwrite behavior, or rate limits, so the description does not fully carry the burden given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening purpose sentence, an expected-shape example, mapping guidance, and an args section. It is front-loaded and every sentence contributes value, though the args section somewhat repeats the shape explanation. Not overly verbose, but a bit longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not mention return values. It covers the main input format well, but omits the config parameter entirely and provides no operational constraints (e.g., batch size, duplicate handling). Given the tool's complexity (3 params, nested objects), the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description compensates by explaining project_id as the project UUID from list_projects or create_project, and thoroughly describes the prompts array with a detailed object shape including required and optional fields. However, the config parameter is not mentioned at all, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add AEO prompts to track for a project' with a parenthetical explaining what AEO prompts are (questions sent to AI answer engines). This gives a specific verb and resource, and it is clearly distinguished from sibling tools like add_tracked_keywords and the aeo_* generation/audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: when adding prompt objects for tracking. It provides explicit instructions on how to shape prompts and how to map columns from a sheet/CSV. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that results are filtered by type and optional query, which is useful behavior context. It does not discuss pagination, response format, or rate limits, but for a simple read-only browse tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose, a one-line return description, and a bulleted list of arguments. Every sentence adds value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 a clear purpose and parameter explanations, the description is largely complete. It covers the main parameters and the read-only safety annotation. It does not describe the response structure, but no output schema exists, and the return type ('segments') is reasonably clear. The 'config' parameter omission slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains segment_type with enumerated values and query with examples, adding meaningful semantics. However, the 'config' parameter is completely undocumented in both schema and description, leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Browse Google Ads audience segments for campaign targeting' using a specific verb ('browse') and resource ('audience segments'). It also specifies the return value: 'Returns available audience segments filtered by type and optional search query', which distinguishes it from siblings like audience_recommendations or demographic_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for campaign targeting and returns segments filtered by type and query. While it doesn't explicitly name alternative tools or give when-not-use cases, the context is sufficient for an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; the description adds value by explaining the returned object (structured recipe with instructions, tool calls, data gathering, presentation format) and advising flexible adaptation. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then explains content, usage adaptation, and the key parameter. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the description covers the core behavior, return value concept, and primary parameter. The unexplained 'config' parameter and lack of explicit sibling differentiation prevent a perfect score, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a detailed Args section for skill_id with meaningful examples, which is necessary since schema description coverage is 0%. However, the 'config' parameter is omitted entirely, leaving it undocumented. The description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Load a specific workflow skill recipe' with a specific verb and resource. It further distinguishes from siblings by describing the recipe content (step-by-step instructions, tools to call, data to gather, presentation). This leaves no ambiguity vs list_skills or read_skill_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context ('Use this as a guide, not a rigid script — adapt steps') but does not explicitly contrast with alternatives like list_skills or read_skill_file. When to use it is implied from the name and description, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=true already covers read-only nature. The description adds context about the indexing status result and the key behavioral trait that search only returns ready documents, which is useful for understanding the eventual consistency model. It doesn't cover pagination or response size, but for a read-only status check this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function and immediately followed by a usage tip. No redundant words, perfectly concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and while the description mentions counts and per-document status, it does not specify the exact response structure or fields. For a tool with moderate complexity, it gives enough to understand the general output but lacks detail on per-document status format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain project_id, collection_id, or config. The parameter names are somewhat self-explanatory, but the description provides no semantic meaning beyond the bare schema, failing to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get a KB's indexing status' with details on counts and per-document status. It distinguishes from sibling tools like kb_search (search returns only ready documents) and kb_get_document (single document), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this after any write' and contrasts with search behavior ('search only returns ready documents'). This gives a clear when-to-use and differentiates from the search tool, though it doesn't mention alternatives like kb_get_document for per-document details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious behavior: KBs are not auto-created on write. It also implies the tool returns an id for subsequent writes. Annotations only provide a title, so the description carries the burden and does so helpfully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core function. Every word earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic purpose and workflow, but lacks parameter semantics (especially config), return value details, and differentiation from sibling tools like kb_create_direct_upload. Adequate for a simple create tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds context for project_id ('in a project') but leaves 'config' completely unexplained and doesn't detail 'name'. The description adds minimal meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Knowledge Base in a project, using a specific verb and resource. It also distinguishes from siblings like kb_delete and kb_list by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: 'KBs are not auto-created on write — create one explicitly, then write documents into it by its id.' This implies when to use it (before writing) and the need to use the returned id later. It doesn't explicitly name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction exists. The description adds that it combines Serpstat and Keywords Everywhere data, which hints at external dependencies, but it does not disclose rate limits, data freshness, or response format. This is mild added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one sentence for purpose, one for data sources, and an Args list. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 no output schema, the description covers the key purpose, metrics returned, and primary parameters/defaults. It stops short of describing the exact output structure or edge cases like unavailable data, but it is sufficiently complete for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explains keyword with a concrete example and country with format and default. However, the config parameter is not mentioned at all, leaving a gap for one of the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Research a keyword' and enumerates concrete outputs: search volume, CPC, competition, difficulty, and trends. This clearly distinguishes the tool from siblings like keyword_rankings or google_trends by focusing on a single keyword's aggregate metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need keyword market metrics, but it does not explicitly state when to prefer this over keyword_planner or google_trends, nor does it mention exclusions. The Args section gives practical defaults, but no alternative-comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which already discloses the safe read-only nature. The description adds the specific data source types and the need for a project_id, but does not mention pagination, return format, or any rate-limit/auth behavior. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the tool's purpose, and includes a clear usage prerequisite. Every sentence adds value; there is no verbosity or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a read-only listing operation), the description provides the core purpose, necessary prerequisite, and example scope. The missing explanation of the config parameter is a minor gap, but the essential use case is well covered, especially with annotations confirming read-only behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 2 parameters, but their schema descriptions are empty. The tool description explains project_id meaningfully ('The project UUID from list_projects()'), which helps. However, the optional config parameter is not explained at all, leaving a gap for a parameter that may affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List connected data sources') and a resource scope ('for a project'), with concrete examples (GSC, GA4, Google Ads). This unambiguously distinguishes it from other list-type tools in the sibling set, such as list_projects or list_folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite and sequence: 'Call list_projects() first to get your project_id.' This is a strong usage guideline. It does not explicitly state when not to use this tool, but the context of requiring a project_id implies its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral context by stating the ordering of contents (skills first, then files) and that skills are 'by reference'. This exceeds the baseline provided by annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief Args section. It is front-loaded with the core purpose and includes no unnecessary words. Every element serves a clear communicative function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required parameter and no output schema, the description covers the essential aspects: what is listed, the order, and where to obtain the folder_id. The config parameter is a minor omission, but the tool is otherwise adequately described given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains folder_id with a source hint ('from list_folders or create_folder'), which adds meaning beyond the schema. However, the optional 'config' parameter is completely undocumented, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('a folder's contents') and specifies the ordering and composition (skills by reference first, then files). This clearly distinguishes it from sibling tools like list_folders and list_skills, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating the folder_id comes from list_folders or create_folder, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent with 'Query.' The description adds that a connected GSC source is required, how to obtain IDs, and specific time ranges for certain endpoints (e.g., 'last 3 months' for top_pages, 'last 2 months' for complete_data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool summary is one sentence, followed by a compact prerequisites line, then a structured Args block with consistent formatting. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description doesn't describe the return format or any pagination/limitations. It also omits 'config.' While the endpoint list gives some idea of output data, it's not fully complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description explains project_id ('Your project UUID'), account_id ('from list_connections, e.g. sc-domain:example.com'), and endpoint (listing each enum value with meaning). However, the 'config' parameter is completely ignored in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query your Google Search Console data — keywords, pages, clicks, impressions, and rankings,' providing a clear verb and resource. However, it doesn't explicitly distinguish itself from sibling tool 'top_pages,' which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear prerequisite ('Requires a connected GSC data source') and provides a specific workflow ('Call list_projects() then list_connections()...'), but it doesn't mention alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only a title), so the description carries the transparency burden. It discloses the critical side-effect that no skill files are copied, only a reference is recorded. While it doesn't cover return values or error handling, the key behavioral trait is well-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, a clarifying note, and an Args section. It is slightly verbose but avoids redundancy and stays focused on essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate: it explains purpose, behavior, and parameter sources. It omits the optional config and does not describe the return value, but these are minor gaps given the tool's straightforward nature and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the two required parameters (folder_id and skill_id) with sources, but the schema also includes an optional 'config' parameter that is completely unaddressed. With 0% schema description coverage, this leaves a gap for the config parameter, though it is likely not essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Attach a skill to a folder by reference') and explains the key nuance that it does NOT copy skill files. This fully communicates the purpose and distinguishes it from any potential copy operation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to obtain the required IDs (list_folders for folder_id, skill store for skill_id) and clarifies the use case (recording a reference rather than copying). It does not explicitly mention alternatives or when not to use, but the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so behavior is read-only. The description adds context about the output categories (in-market, affinity, demographics, bid modifiers) but does not disclose any additional behavioral traits such as rate limits, authentication requirements, or whether external AI calls occur. No contradiction with annotations, but limited extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The second sentence elaborates on outputs, and the 'Args' block is a compact, scannable list of parameters. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must cover return structure; it lists the categories returned but not the format (e.g., score/confidence values, structure). The undocumented 'config' parameter is a gap. For a tool of this complexity, the description is mostly sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains three of four parameters (keywords, campaign_type, industry) with examples and defaults. It clarifies allowed values for campaign_type and typical industries. However, the 'config' parameter is completely absent from the description, leaving its purpose unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get AI-recommended audience signals for a Google Ads campaign.' It specifies the resource (audience signals) and action (get/recommends), and lists concrete output types (in-market segments, affinity audiences, demographics, bid modifiers). This distinguishes it from sibling tools like audience_segments or demographic_options by emphasizing AI-driven, keyword-based recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is used when you want audience recommendations based on keywords and industry. However, it does not explicitly contrast with alternative tools or state when not to use it. The examples and default values give practical guidance, but there is no explicit exclusions or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a title, so the description carries the burden of disclosing behavior. It does state that the operation is scoped to the authenticated user and returns a new project_id. However, it omits the `config` parameter's role, does not discuss duplicate-name behavior, and provides no side-effect or error information beyond the act of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the essential purpose. The intro is followed by workflow context, return value, and a concise Args list. Every sentence contributes value without redundancy or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter create tool with no output schema and no safety annotations, the description covers purpose, workflow, return value, and most parameters. However, the undocumented `config` parameter is a notable gap, and there is no mention of error conditions or idempotency, making the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It provides meaningful explanations for name, domain, keywords, competitors, and industry, including accepted formats for keywords and competitors. It fails to mention the `config` parameter present in the schema, leaving one of six parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new Unilytics project for the authenticated user,' using a specific verb and resource. It also distinguishes itself from sibling tools like list_projects by describing project creation as the entry point for adding tracked keywords and uploading files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual usage: 'Use this to set up a project from Claude — then add tracked keywords/prompts and upload files to it.' This indicates when the tool should be used in a workflow. However, it does not explicitly mention when not to use it or suggest alternative tools for viewing or managing projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint, but the description adds valuable context beyond these: it emphasizes the permanence of the deletion and the scope ('ALL its documents'), and adds the user-confirmation requirement. This provides the agent with critical behavioral information without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with what the tool does ('Permanently delete a Knowledge Base and ALL its documents') followed by a warning and idempotency note. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description covers the essential aspects: permanent deletion, scope, user confirmation, and idempotency. The only missing piece is parameter semantics, but the required IDs are clear from the schema titles and the tool's purpose. Overall, it is sufficient for an agent to invoke this tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters. Required params project_id and collection_id are somewhat self-explanatory from titles, but the optional config parameter is completely opaque. The description does not compensate for the lack of schema descriptions, leaving the config param ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a Knowledge Base and ALL its documents,' which specifies the exact resource and scope of the action. This distinguishes it from sibling tools like kb_delete_document, which deletes individual documents, and kb_manage/kb_update, which modify or manage KBs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by warning 'DESTRUCTIVE — confirm with the user before calling,' indicating when this tool is appropriate (only after user confirmation). The phrase 'ALL its documents' implies that this is for whole-KB deletion, not for deleting individual documents, though it does not explicitly name the alternative tool kb_delete_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide a title, so the description carries the full burden of behavioral disclosure. It does well by explaining that the operation is a full replacement ('in full'), that it does not merge or re-embed, and how to remove keys. It lacks details on permissions, reversibility, or return values, but the provided behavioral traits go beyond what the name or schema alone imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every sentence earns its place. It is efficient and avoids unnecessary detail, providing essential behavioral information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations beyond a title and no output schema, so the description needs to be comprehensive. It covers the core operation and key constraints (full replacement, no re-embed, removal method, searchability). However, it does not mention what happens on success/failure, the return format, or the purpose of the 'config' parameter, leaving some gaps for an agent trying to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explicitly explains the 'metadata' parameter as a 'single-level key/value hash' and how to remove keys, which adds meaning beyond the schema. However, it does not explain 'config', nor does it add details for 'project_id' or 'document_id', although those are fairly self-explanatory. The compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Replace a document's metadata (single-level key/value hash) in full'. It uses a specific verb ('Replace') and resource ('document's metadata'), and distinguishes from sibling tools like kb_update_document by focusing solely on metadata. The phrase 'no merge, no re-embed' further clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when you need to perform a full replacement of metadata, not a merge. It also notes that the result is 'Filterable via kb_search', implying usage after metadata changes. However, it does not explicitly name alternative tools or state when NOT to use this tool, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that screenshots are taken after JavaScript execution and that full_page controls viewport vs. full scrollable page. This adds valuable behavioral context. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, followed by use cases in a sentence, then an Args list. Every sentence adds value with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, this description covers the main aspects: what it does, common use cases, key arguments, and a behavioral note. However, it omits any explanation of the 'config' parameter and does not describe the return value or output format, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains 'url' and 'full_page' with meaningful descriptions, partially compensating for the 0% schema coverage. However, the 'config' parameter from the schema is completely omitted, leaving its purpose unclear. The description does not fully compensate for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Capture a screenshot of a webpage.' It further specifies 'after JavaScript execution,' distinguishing it from simple scraping tools like content_scrape or js_scrape. This clearly differentiates the tool from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists explicit use cases: 'visual audits, above-the-fold analysis, competitor page comparison, UX review, or documenting current page state.' This provides clear context for when to use the tool, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent with the description. The description adds value by detailing what the audit produces (intent, metric, play, recommendation) and the expected input structure. It does not contradict annotations and provides useful behavioral context beyond the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: a concise summary followed by the parameter format. Both sentences are informative and necessary, with no fluff or repetition of schema information. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the nature of outputs (per-prompt intent, metric, play, recommendation). It also covers the key input structure. However, it leaves some jargon undefined (e.g., 'play', 'realistic metric') and does not clarify the exact return format, which might be ambiguous for a general agent. Still, for a specialized AEO tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does for the required 'prompts' parameter by specifying the structure: [{id, text, intent?, mention_rate?, citation_rate?}]. However, it does not explain 'config' or 'use_llm', though these are optional and their names are somewhat self-explanatory. The main required parameter is well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Audit a tracked-prompt set' with specific outputs (per-prompt intent, metric, play, keep/cut/rewrite recommendation). This distinguishes it from siblings like aeo_generate_prompts (generate) and aeo_filter_prompts (filter), which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auditing existing tracked prompts but does not explicitly state when to use it versus alternatives like aeo_generate_prompts or aeo_filter_prompts. There are no when-not-to-use guidelines or alternative names mentioned, leaving the context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds rich behavioral context: it lists exactly what junk categories are removed (operators, year-stamps, foreign, geo, brand-variants, other-brands, dupes), specifies input format (items = [{text}] or [str]), and states the return shape {kept, removed, summary}. This clearly communicates a non-destructive analysis operation, going beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that starts with the action ('Clean...'), then lists remove targets, input format, and return structure. Every clause is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the high-level function, input format, and return shape, but with 5 parameters and no schema descriptions, it leaves optional parameters like config and competitor_domains under-explained. For a filtering tool with nuanced controls, this is a notable gap, though the core workflow is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explains the 'items' parameter format explicitly ('items = [{text}] or [str]') and hints at brand/geo/competitor behavior through the junk categories, but does not explicitly map parameters like 'brand', 'config', 'geo_target', and 'competitor_domains' to their functions. 'config' is entirely unexplained, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it cleans an imported keyword/prompt list by removing junk categories such as operators, year-stamps, foreign, geo, brand-variants, other-brands, and dupes. This specific verb+resource combination distinguishes it from sibling AEO tools like aeo_cluster_prompts, aeo_audit_prompts, aeo_generate_prompts, and aeo_prompt_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: when you have an imported list that needs cleaning/filtering before further AEO processing. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to guide selection. Missing explicit 'use instead of' guidance, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes it's a safe read operation. The description goes beyond that by explaining what the memory contains ('durable lessons, workarounds, and user preferences') and how it improves runs. This provides meaningful context beyond the annotation, though it doesn't cover edge cases like missing memory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a concise purpose statement, a practical usage tip, and a clear Args section. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides sufficient context: purpose, timing, and the key parameter. The only gap is the unexplained 'config' parameter, but since it's optional with a default null, the agent can still invoke the tool correctly by omitting it. The description is nearly complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds valuable context for skill_id, including examples ('seo/keyword_research') and clarification of built-in vs user/project IDs. However, the 'config' parameter is completely undocumented, and with 0% schema description coverage, the description only partially compensates for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read a skill's accumulated MEMORY (learnings/workarounds from prior runs).' This clearly distinguishes it from sibling tools like get_skill (which likely reads skill definitions) and read_skill_file (which reads files), by emphasizing the 'MEMORY' concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool: 'Call this at the START of running a skill.' It also explains the value (carries durable lessons, workarounds, preferences). However, it does not explicitly mention alternative tools or specify when not to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a title, so the description carries the transparency burden. It discloses that the file's text is 'extracted, chunked, and embedded' and that the tool returns a status to poll, implying asynchronous processing. This adds meaningful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact paragraph of about 50 words, front-loaded with the step context. Every sentence contributes useful information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description covers the workflow, return shape, and polling requirement well. However, with 7 parameters, some parameter semantics and error/edge-case details are missing, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the role of signed_id in the upload workflow but does not clarify the other parameters (config, metadata, document_type). Some compensation exists, but several parameters remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as 'Step 2 of a two-step file upload' with a specific action: create a KB document from the uploaded file's signed_id. It distinguishes from sibling tools like kb_create_direct_upload (step 1) and kb_get_status (polling) by naming them directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context by referencing the prerequisite (PUT to upload_url from kb_create_direct_upload) and the follow-up (poll kb_get_status). While it does not explicitly mention alternatives like kb_write_text or kb_add_urls, the step-based framing makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses asynchronous behavior (returns a job id), the scraping and ingestion process, and the metadata hash applied to every document. With no annotations to carry safety or behavior hints, these details meaningfully raise transparency, though failure modes and auth are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core action first, then return behavior and a metadata nuance. Every word contributes, and the description is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and minimal annotations, the description covers the essential workflow: add URLs, get job id, poll kb_get_status. It would benefit from mentioning config or edge cases, but is largely complete for a straightforward ingestion tool among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 implies semantics for urls (each becomes its own document) and metadata (same hash applied to all), but does not explain project_id, collection_id, or config. This adds value over the raw schema but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Add one or more webpage URLs to a KB' with each URL scraped and ingested as its own document. This distinguishes it from sibling tools like kb_add_file and kb_create_direct_upload, which handle other ingestion methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (adding URLs, each becoming a document) and explicitly instructs to poll kb_get_status for per-document completion. It doesn't explicitly mention alternatives or exclusions, but the workflow guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true, and the description adds meaningful behavioral detail by stating exactly what the tool returns: internal vs external links, anchor text, nofollow attributes, and link counts. This goes beyond the annotations and offers concrete output expectations, though it lacks caveats about page-size limits or rate restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized: a two-line summary, an output specification, a use-case list, and Args. Every sentence contributes functional value, and the structure is scannable. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, return values, and common use cases, which is sufficient for an agent to select and invoke it. The only notable omission is the undocumented 'config' parameter and any mention of result limits or error behavior. Since no output schema exists, the return description is helpful, but the config gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section compensates by explaining 'url' (with an example) and 'js_rendering' (default false). However, the 'config' parameter is entirely undocumented, leaving an unexplained field. This partial coverage gives a baseline but clearly has a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Extract and classify') and resource ('all links from a webpage'), and further details the output (internal vs external links, anchor text, nofollow attributes, link counts). This clearly distinguishes the tool from sibling crawl/scrape tools, meeting the highest bar for purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists five distinct use cases (link audits, outbound analysis, internal linking reviews, competitor link building opportunities, nofollow distribution) which gives clear context for when to use the tool. However, it does not mention alternatives or specify when not to use it, so it falls short of the full 'when/when-not/alternatives' definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the safe read-only nature. The description adds that it returns active ad creatives, spend ranges, and targeting info, which is useful output context. It does not disclose any rate limits, pagination behavior, or the ambiguous 'config' parameter, but with annotations covering safety, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a clear purpose line, a brief output summary, and a concise Args block. It avoids redundant fluff while providing examples and defaults. Front-loaded with the most important information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description's summary of return data is helpful. It covers the main parameters and gives a realistic use case. The main gap is the unexplained 'config' parameter and the absence of any mention of pagination or special constraints, but given the relative simplicity and readOnly annotation, the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its properties, so the description's Args section is essential. It explains query with examples, country as a two-letter code with a default, and limit as max results. However, it omits the 'config' parameter entirely, leaving its purpose undefined. With 3 of 4 parameters clarified, the description compensates well but not completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Search the Meta Ads Library for competitor ads on Facebook and Instagram.' It clearly distinguishes itself from siblings like google_ads_transparency and competitor_ads by naming the exact platform and use case. The additional output details (active ad creatives, spend ranges, targeting info) reinforce the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for searching Meta's ad library for competitor research. However, it does not explicitly mention when to avoid this tool or name alternative tools for other ad platforms. The context is sufficient for most cases, so a score of 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds valuable behavioral context: it 'recursively follows internal links,' enforces a max_pages limit (with a max of 100), and lists returned per-page SEO signals (title, meta description, headings, issues). This goes beyond the annotation, though it does not discuss rate limits or robots.txt behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening purpose, a concise use-case paragraph, and an Args list. Every sentence contributes value—use cases inform when to use, and the Args section clarifies parameters. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a complex crawling tool with no output schema, the description covers the essentials: what it does, how it behaves (recursion, max_pages), what it returns, and when to use it. The only notable omission is the undocumented 'config' parameter, but the overall description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains url and max_pages, including default and maximum values, which adds meaning beyond the schema. However, the schema also includes a 'config' parameter that is completely absent from the description, leaving one of three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Crawl a website and return data for every discovered page (up to max_pages).' It clearly distinguishes this from sibling tools by emphasizing recursive full-site crawling and listing concrete use cases like site-wide audits, internal link analysis, and orphan page detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use for site-wide audits, content inventory, internal link analysis, finding orphan pages, detecting missing meta tags across a site, or any task needing full-site data.' However, it does not mention when not to use it or compare it to alternative tools, so it lacks exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates that this is a safe read-only operation. The description adds useful context about the data fields returned and the platform scope, but it does not disclose potential behavioral traits such as auth requirements, rate limits, or error behavior. Given the annotation covers the core safety profile, the description provides some additional value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The opening sentence states the core purpose, the supported platforms are listed in one sentence, and the args list is compact with examples and defaults. Every sentence provides value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite not having an output schema, the description mentions the return data (followers, bio, recent posts/videos). It also covers the supported platforms and parameter behavior. The main gap is the undocumented 'config' parameter and lack of information about error handling or limitations. Overall, the description is reasonably complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains url with an example, enumerates valid platform values ('facebook', 'instagram', 'youtube', 'twitter'), and clarifies max_posts with its default and purpose. However, it does not mention the 'config' parameter at all, leaving a gap for one of the four schema parameters. Overall, it adds significant meaning beyond the schema for the key parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Scrape a social media profile' and lists the data obtained (followers, bio, recent posts/videos). It also explicitly names the supported platforms (Facebook, Instagram, YouTube, Twitter/X), distinguishing it from generic scraping tools like content_scrape or js_scrape. This is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the supported platforms, giving the agent context for when to use this tool (i.e., when the URL belongs to one of these social media platforms). However, it does not explicitly mention when not to use it or mention alternative tools, so it lacks exclusionary guidance. This aligns with 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Exceeds annotations by describing exact return shape, top-20 fetch limit, near_miss semantics as weak evidence, and spell content. Read-only nature is already in annotations; description adds meaningful operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with purpose, and every sentence adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it covers return structure, near_miss semantics, and spell usage well. The only notable gap is the undocumented config parameter, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description partially explains top_n via near_miss threshold and keyword via 'keyword/prompt', but config is entirely unexplained. Fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns top Google organic results with rank, near_miss, and spell, distinguishing it from generic SERP tools. The output structure is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when near_miss should be used (refresh candidates) versus when it should not (claiming page ranks). Also mentions spell for detecting query drift, but does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only a title annotation and no readOnly/destructive hints, the description carries the full burden of behavioral disclosure. It reveals return values ({signed_id, upload_url, content_type}), the requirement to PUT bytes to the URL, and allowed file types with a max size. It does not mention authentication or error behavior, but the core behavior is well-covered for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it front-loads the purpose, then lists return values, usage steps, and constraints in a compact, logical order. Every sentence provides necessary information without redundant fluff. It is slightly longer than minimal but earns each sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no parameter descriptions, the description provides a strong overview of the workflow, return values, and limits. However, it leaves parameter semantics to be inferred and does not address potential errors or edge cases, which prevents a perfect score. Overall, it is fairly complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it does not explain individual parameters like byte_size, content_type, config, or project_id. It mentions 'filename' only implicitly by discussing file upload. The workflow hints at some meanings, but key parameters like byte_size and config remain obscure. This is a significant gap given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Step 1 of a two-step file upload: get a presigned URL to upload a file into a KB.' It uses a specific verb ('get') and resource ('presigned URL'), and distinguishes itself from the sibling tool kb_add_file, which is the second step. This makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool and how to chain it with the alternative: 'then call kb_add_file with the signed_id.' It provides step-by-step instructions (PUT to upload_url, use content-type header) and specifies supported file types and size limit, giving clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly/destructive annotations, the description carries the burden. It discloses that content is embedded and becomes searchable, returns {document_id, status}, metadata is single-level and filterable, and that ingestion is asynchronous. This goes beyond bare mutation but doesn't cover overwrite behavior or auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no fluff. Every sentence adds value: what it writes, return value, async status, metadata structure. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with async ingestion, it covers the full flow: create, get status, search readiness, and metadata filtering. No output schema exists, but the return shape is explicitly described, making the description complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It explains 'content' (text/markdown) and 'metadata' (single-level key/value, filterable), but leaves 'config', 'project_id', 'collection_id', and 'name' unexplained. These are mostly self-explanatory, yet 'config' remains ambiguous, preventing a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Write an inline text/markdown document into a KB' with examples (research summary, agent output, notes), distinguishing it from sibling tools like kb_add_urls and kb_add_file. Verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies appropriate use by specifying 'inline text/markdown' versus URL/file uploads, and provides workflow guidance (poll kb_get_status, search after 'ready'). However, it does not explicitly name alternatives or state when not to use, so deducts a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds value by specifying the scope of the results ('all projects you own or have access to') and implies the response includes project_id, which is useful despite being a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and the second sentence adds practical usage context without unnecessary detail. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately explains what it does and what the agent can expect (project_id). The only gap is the unexplained 'config' parameter, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'config' parameter with no description, and the description doesn't explain it either. With 0% schema description coverage, the description should compensate but doesn't, leaving the agent without guidance on what 'config' is for, though the default null allows calls without it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List your Unilytics projects' with a specific verb and resource. It also distinguishes itself from sibling tools by noting it shows all projects you own or have access to, which differentiates it from list_connections and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this first to discover your project_id, then use list_connections()... and search_console_data()'. This tells the agent when to use this tool and how it fits into a workflow, clearly indicating it is the entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint already establishes this as a read-only operation, and the description adds useful behavioral detail: it performs progressive disclosure, keeps context lean, and advises reading a script before running it. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence and an Args section. It is slightly longer than strictly necessary but every sentence adds value—progressive disclosure guidance, the relationship to get_skill, and a script-running note. No fluff, but it could tighten the phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description gives enough context for the expected file-loading behavior, points to get_skill for the file list, and clarifies path aliases. It does not explicitly describe the return format or error cases, but for a read-only file loader with readOnlyHint, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains skill_id (user/... or project/... for editable skills) and path (file path within the skill), plus notes file_path as an alias. However, the config parameter is completely undocumented, and schema description coverage is 0%, leaving at least one parameter's semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Load one reference/data file of a skill, on demand (progressive disclosure)', which clearly identifies the verb (load), resource (reference/data file), and scope (within a skill). It also distinguishes itself from get_skill by positioning it as the complementary per-file loader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: after get_skill() returns the SKILL.md contract and the list of files, call this to load a specific file only when needed. It also names the sibling tool get_skill and even provides an example path convention, giving clear usage context and differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the operation appends to existing lists with no duplicates, and that inputs can be lists or comma-separated strings. Since annotations only include a title, the description carries the burden and adds meaningful behavioral context, though it lacks details on error handling or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, a usage note, and a parameter list. Every sentence adds value, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, prerequisites, parameter semantics, and constraints. The omission of the 'config' parameter and lack of return value details are minor gaps, but overall it is sufficiently complete for a simple append operation without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the Args section in the description is essential. It explains project_id, keywords, competitors, and locations with types and semantics. However, the 'config' parameter in the schema is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds tracked keywords, competitors, and/or target locations to a project. The verb 'Add' and resource are specific, and it distinguishes itself from the sibling tool add_tracked_prompts by naming the exact entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite (call list_projects() first to get the project_id) and a constraint (at least one of keywords/competitors/locations must be provided). However, it does not explicitly mention alternatives or when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation, and the description complements it by noting the requirement for a connected data source and specifying per-endpoint date ranges (e.g., last 2 months, last 3 months). There is no contradiction between the annotation and the query language used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is a clear, front-loaded summary. The required-ID lookups are explained in one concise sentence, and the endpoints are presented in a scannable bullet list. Every sentence provides necessary context, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, ID lookup steps, endpoint choices, and the time ranges for each endpoint, which is strong for selecting the right query. It does not describe the output/return format, and with no output schema that information is absent, but the data types listed in the endpoints give reasonable inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage), so the description carries the full burden. It clearly explains project_id, account_id, and each endpoint enum value along with what data they return. However, the optional 'config' parameter is not mentioned at all, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Query your Google Analytics 4 data', and enumerates the metrics it covers (sessions, users, conversions, traffic sources, device breakdown). This clearly distinguishes it from sibling tools like search_console_data and google_ads_data, which target different data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit prerequisites ('Requires a connected GA4 data source') and a clear step-by-step guide to find the required IDs by calling list_projects() and list_connections(). It does not explicitly mention when not to use this tool or name alternatives, but the GA4 scoping makes the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds valuable behavioral context beyond the annotation: the requirement of a connected data source, how to obtain necessary IDs, and endpoint-specific time windows (e.g., all time vs. last 3 months). This goes beyond the safety profile declared by annotations, though it doesn't cover rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening statement, a concise prerequisite note, and a bulleted argument list. Every sentence adds value, and information is front-loaded. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, so the description must compensate. It covers prerequisites, each endpoint's data types, and time ranges, making it reasonably complete. However, it omits the config parameter and does not describe the exact response format or pagination behavior, which are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, so the description carries the full burden. It explains project_id, account_id, and endpoint thoroughly, including detailed explanations of each enum value with time ranges and data types. However, the 'config' parameter is completely undocumented, leaving a gap in parameter coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries 'your own Google Ads account data' with a specific list of data types (clicks, impressions, campaigns, keywords, ad copy). This distinguishes it from siblings like google_ads_transparency, which likely handles public ads data, and other analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for own Google Ads data) and even lists prerequisites (connected data source, calling list_projects() and list_connections() to get IDs). However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true, so the description does not need to justify safety. It adds context beyond annotations by stating the output includes ad creatives, target domains, and links, and by warning to use a domain rather than a brand name for advertiser_name. This gives useful behavioral insight without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a one-sentence summary of return values, and a clearly formatted Args block. Every part is relevant and there is no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately explains return values in one sentence. It also covers three of four parameters with helpful defaults and examples. The missing 'config' parameter and lack of any guidance on pagination or rate limitations prevent a perfect score, but overall it is complete enough for a straightforward read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description takes on the burden of explaining parameters. It documents advertiser_name, region (with default and common codes), and limit (with default and max). However, the 'config' parameter from the schema is entirely undocumented, which is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'See what Google Ads a competitor is running via the Ads Transparency Center.' It clearly states the tool's function and distinguishes it from sibling tools like competitor_ads and meta_ads_library by focusing on Google Ads and the transparency center.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for viewing a competitor's Google Ads via the Ads Transparency Center. It also gives usage guidance for the advertiser_name parameter ('Use domain, not just brand name'). However, it does not explicitly mention when not to use it or suggest alternative tools like google_ads_data for own ads or meta_ads_library for Facebook ads, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which covers the safety profile. The description adds behavioral context such as waiting for JavaScript to fully execute and returning SEO audit signals. It also specifies the wait_for parameter's default and max values, but does not describe error handling or timeout behavior, so it is not fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear introduction, comparison, use cases, return summary, and Args section. It is concise and front-loaded with the tool's purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality, including what it returns (SEO audit signals). However, it fails to explain the config parameter, and does not address edge cases such as slow-loading pages or error handling. Given the tool's complexity, it is reasonably complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents url and wait_for with examples and defaults, but entirely omits the config parameter from the schema. Since schema description coverage is 0%, this is a clear gap. The wait_for documentation adds max and default values beyond the schema, but the config parameter remains unexplained, making it a minimum viable score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes JavaScript-rendered pages, specifically SPAs, React, Vue, and Angular apps. It distinguishes from a standard scrape by mentioning it waits for JS execution, which is a clear differentiator even if the sibling is not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: for single-page applications, dynamic content, or any page where content loads via JS. It also contrasts with the standard scrape, implying that for non-JS pages the standard scrape should be used, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint and idempotentHint, but the description adds crucial context: what exactly gets destroyed ('drops its indexed chunks') and the idempotent behavior in plain language. This goes beyond the structured hints and clearly explains the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes necessary warnings. Every word adds value: destructive warning, idempotency note, and side-effect explanation. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with strong annotations, the description covers all essential aspects: what it does, side effects, user confirmation requirement, and idempotency behavior. No output schema exists, but return values are not critical for a delete operation. The description is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'one document from a KB' which vaguely maps to document_id and project_id, but it does not explain the parameters' formats, the optional config field, or how the identifiers are used. The schema titles 'Project Id' and 'Document Id' are self-explanatory, but the description adds no meaningful parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently delete one document from a KB' with a specific resource (document) and scope (one document, from a KB). It also distinguishes from sibling tools like kb_delete (likely for whole KB deletion) by mentioning 'one document' and 'drops its indexed chunks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'DESTRUCTIVE — confirm with the user before calling' and notes idempotency ('deleting an already-deleted doc is a no-op'). It does not explicitly name alternative tools for non-destructive needs, but the destructive warning makes the appropriate context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint: true in annotations, the description adds value by explaining that queries should be in the same language as documents, that results are top matching chunks with source and score, and that scoping/filtering is optional. It provides more behavioral detail than a simple read-only flag, without any contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence earns its place. There is no redundant information or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description covers the return value (top chunks, source, score) and the query format, which is adequate for core use. The unexplained 'config' parameter and lack of mention of required fields (though schema handles that) are minor gaps, but overall the description is sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the responsibility of explaining parameters. It successfully maps most params: project_id ('a project's KB'), query ('natural language'), collection_id ('scope to one KB'), metadata_filter ('filter by metadata'), and max_results ('top matching chunks'). However, the 'config' param remains completely unexplained, a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Semantic search across a project's KB' with a specific verb and resource. It further distinguishes from sibling KB tools like kb_list or kb_get_document by describing the output ('top matching chunks with their source + score') and the natural language query requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for semantic search on a project's KB, highlighting natural language input and optional scoping or filtering. It does not explicitly exclude alternatives or name when not to use it, but the context is clear enough for an agent to select this tool over listing or document retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no destructive/read-only annotations, the description carries the full burden of disclosing side effects. It explicitly warns that a resync rebuilds the index and that agent metadata must be re-applied afterward, and it mentions the status lifecycle (ready→pending→ready). This is essential behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences, front-loaded with the core purpose, then the mode selection, then the critical side-effect note. Every sentence adds value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's core behavior, two input modes, status transition, and side-effect warning are all covered, which is sufficient for a single-document update. It doesn't describe return values (no output schema) or clarify interactions like passing both url and content, but these are non-critical gaps given the concise and informative description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 explains the meaning of `url` and `content` and their appropriate use cases, but leaves `name` and `config` unexplained. Required params `project_id` and `document_id` are self-evident from their names, but full parameter semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Refresh') and resource ('a document's content in place') while explicitly noting it keeps the SAME document_id, clearly distinguishing it from tools that create new documents or update metadata. It also differentiates between URL and text document modes, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear guidance on when to pass `url` vs `content` (for URL docs vs text docs), which is the primary selection criterion. It does not explicitly name alternatives like kb_update_document_metadata, but the distinction between content refresh and metadata update is evident from the description and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'replaces the old entries with your summary,' which highlights the destructive/overwriting behavior. It also notes that it should only be called when memory is full, indicating a state-dependent side effect. However, with no annotations providing safety hints, the description could go further by mentioning authorization requirements or reversibility, but the core behavioral impact is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a clear trigger/usage paragraph, and a bulleted Args section. Every sentence adds value, with no redundant fluff.This is an example of effective, efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is largely complete: it covers what the tool does, when to call it, and what the main arguments mean. However, it omits the return value/expected outcome (e.g., whether it returns the new summary or a success status) and does not clarify the optional config parameter. These are minor gaps, but the description still gives an agent enough to proceed safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the two required parameters: skill_id ('The skill whose memory to compact') and summary ('The distilled summary of durable lessons to keep'). This adds meaningful context beyond the bare schema. However, the optional 'config' parameter is completely undocumented, leaving its purpose unclear. Since two of three parameters are well described, the description mostly compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compact a skill's MEMORY into one summary entry (when it gets large).' It identifies the specific resource (memory), the action (compacting into a summary), and the condition (when large). It also distinguishes itself from related tools by referencing append_skill_memory, showing a unique trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this only when append_skill_memory returns memory_full.' It also gives a step-by-step workflow ('Read the memory, distill the durable lessons into a concise summary, and pass it here'), which clearly instructs when and how to invoke the tool. This differentiates it from alternatives and sets a strong precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint annotation, the description adds substantial behavioral detail: greedy centroid assignment, absolute shared-URL counts, join eligibility rules, quarantine behavior, and rank-weighted page assignment. It also discloses that certain joins are never auto-accepted and come back with needs_review=true. This far exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It opens with the core purpose, then details algorithm, inputs, config, and output in a logical flow. No filler or repetition; the structure mirrors the tool's execution process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (nested objects, no output schema), the description is remarkably complete. It covers input formats, config schema, algorithm behavior, output fields, and edge cases (needs_review, quarantine). An agent could confidently invoke this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 thoroughly explains the 'items' structure (including legacy fields and citation_urls as a separate signal) and the 'config' structure (per-project, nothing hardcoded). However, it does not explicitly describe the 'page_inventory' parameter, leaving a minor gap in an otherwise detailed explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool clusters prompts by shared Google SERP URLs and assigns each cluster a page. This is a specific verb+resource combination that clearly differentiates it from siblings like aeo_cluster_prompts, which likely cluster by different criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for clustering prompts by URL overlap) and explains key algorithmic constraints (e.g., no transitive chaining, quarantine of query-drift SERPs, needs_review for certain joins). It does not explicitly name alternative tools or exclusion criteria, but the behavior is well-defined enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the minimal annotation (title only). It discloses key behaviors: extends seeds from a built-in, verbatim_source triggers a coverage-based fidelity check with potential FAIL signaling silent condensation, and the progressive disclosure file layout. This gives the agent a thorough understanding of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though the description is long, every section earns its place. It is front-loaded with the core purpose, then usage, file layout, and parameter details. The structured formatting (bold section headers, bullet lists) makes it scannable and digestible despite its length. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params, no output schema, no enums), the description is remarkably complete. It explains the full workflow, file layout, parameter constraints, and the verbatim_source fidelity checking behavior. Agents have enough information to select and invoke the tool correctly without needing external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 10 parameters and 0% schema description coverage, the description compensates fully by explaining each parameter's meaning, default, and special cases. For example, it clarifies that skill_markdown is required unless extends is given, and that project_id is required when scope='project'. This adds substantial value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new editable skill (a SKILL.md + optional reference/data files come later via update_skill).' It distinguishes from siblings like update_skill and author_skill by explicitly defining its role in the skill lifecycle. The mention of customizing built-ins via extends further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Use this to author a skill from Claude, or to CUSTOMIZE a built-in (pass extends=...)' and it points to author_skill() for the full guide. It also clarifies that reference/data files come later via update_skill, providing clear context for when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given annotations provide only a title, this description carries full behavioral disclosure burden. It discloses that the tool writes a new version with no publish step, describes exact matching behavior for file_edits (count must match exactly), explains that SKILL.md is undelatable, and details the fidelity report behavior for verbatim_source. It also reveals version conflict handling via expected_version and read-only enforcement for built-ins.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized into labeled sections (FILE LAYOUT, Args) with bullet lists and examples. Every sentence adds unique value: matching rules, storage location semantics, read-only constraints, and parameter behaviors. The length is justified by the tool's complexity, and key points are front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, nested objects, no output schema, and minimal annotations, meaning the description is the only source of contextual guidance. It covers file placement conventions, limitations (SKILL.md undeletable), version conflict behavior, and fidelity checking for ported content. This provides complete operational knowledge for an agent to use the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates. It explains the structure and purpose of each parameter with examples: file_edits mapping, file_changes mapping, delete_files array, change_summary purpose, expected_version conflict semantics, and verbatim_source fidelity reporting. This goes far beyond the raw schema, which only lists names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Save changes to an editable skill — writes a new version (no publish step)', which clearly states the action, target resource, and key distinction from publishing. It distinguishes itself from siblings like create_skill (which creates new skills) and delete_skill (which removes skills), and the mention of 'editable skill' clarifies it does not apply to read-only built-ins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use which parameter: 'Prefer file_edits for small changes' and 'Use for new files or large rewrites' for file_changes. It also explains when NOT to use the tool: 'Built-in skills are read-only — update is rejected; create_skill(extends=...) first, then update that copy.' This directly addresses alternative tools and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![unilytics-mcp MCP server](https://glama.ai/mcp/servers/TeamUnilytics/unilytics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TeamUnilytics/unilytics-mcp)

Score Badge

Copy to your README.md:

[![unilytics-mcp MCP server](https://glama.ai/mcp/servers/TeamUnilytics/unilytics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TeamUnilytics/unilytics-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TeamUnilytics/unilytics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server