Classify keywords locally by intent, funnel stage, brand type, and topic. Free and available without an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Keywords to classify | |
| brand_name | No | ||
| competitors | No | ||
| brand_variations | No | ||
| product_keywords | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that processing happens locally (no external API calls) and requires no authentication ('without an API key'), which are useful behavioral traits. It does not detail the return format or potential limitations, but for a simple classification tool, the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise at two sentences, immediately stating the tool's purpose and key traits. Every word adds value—'locally' and 'free without API key' are substantive, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (4 optional), no output schema, and no annotations, the two-sentence description is insufficiently complete. It does not explain how to use the optional parameters or what the classification output looks like, leaving a significant gap for an agent attempting to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'keywords' is described), yet the description does not compensate by explaining the optional parameters such as 'brand_name', 'competitors', 'brand_variations', or 'product_keywords'. The high-level list of classification dimensions (intent, funnel stage, brand type, topic) gives some context but does not clarify how these parameters influence classification, leaving them under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Classify keywords locally by intent, funnel stage, brand type, and topic.' This uses a specific verb (classify), identifies the resource (keywords), and lists the classification dimensions, effectively distinguishing it from sibling tools that focus on URL structure, guidelines, and SEO guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting it operates 'locally' and is 'Free and available without an API key,' implying it is a self-contained, no-cost option. While it does not explicitly name alternatives or state when not to use it, this contextual guidance is sufficient for an agent to infer its suitability for offline, keyless keyword classification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct: analyze_url_structure and classify_keywords_simple perform concrete analyses, while get_google_guidelines, seo_guidance, seo_checklist, get_skill, and list_locations serve different informational purposes. However, seo_guidance, seo_checklist, and get_google_guidelines could be somewhat confused as all provide SEO advice in different forms.
Naming mixes verb_noun patterns (analyze_url_structure, get_google_guidelines, list_locations) with noun-only names (seo_checklist, seo_guidance). The 'seo_' prefix is used inconsistently, and 'classify_keywords_simple' includes an extraneous modifier. While readable, the pattern is not uniform.
Seven tools is a well-scoped number for a server focused on SEO guidance and analysis. Each tool covers a distinct aspect, and this count is neither too sparse nor overwhelming.
The server provides solid coverage of SEO guidance and reference material but lacks broader analysis tools (e.g., on-page content analysis, backlink checks, ranking queries). The presence of list_locations hints at integration with other data tools that are not included, leaving noticeable gaps in a fully functional SEO toolkit.
