WP Navigator MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: wpnav_context provides site context for initialization, wpnav_describe_tools gives detailed schemas, wpnav_execute runs tools, wpnav_introspect reveals API capabilities, and wpnav_search_tools finds tools by query. Their descriptions explicitly differentiate their roles and usage sequences.
Naming Consistency5/5
All tools follow a consistent 'wpnav_' prefix with descriptive snake_case names (e.g., wpnav_context, wpnav_describe_tools). This pattern is uniform across all five tools, making them predictable and easy to identify as part of the same server.
Tool Count5/5
With 5 tools, the count is well-scoped for a WordPress navigation server. Each tool serves a specific function in the workflow (discovery, description, execution, context, and introspection), and none feel redundant or missing for the apparent purpose of managing WordPress tools.
Completeness5/5
The tool set provides complete coverage for the WordPress navigation domain: wpnav_introspect and wpnav_context handle initialization and understanding, wpnav_search_tools and wpnav_describe_tools cover discovery and schema retrieval, and wpnav_execute enables action. This creates a seamless workflow with no obvious gaps or dead ends.
Average 4.2/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'compact context dump' and mentions token usage implications ('~200-300 tokens,' 'Increases token usage'), which adds useful behavioral context. However, it does not detail aspects like rate limits, error handling, or authentication needs, leaving some gaps for a tool with no 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 appropriately sized and front-loaded, with the first sentence covering the core purpose and components, and the second sentence adding key usage context. Every sentence earns its place by providing essential information without redundancy 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 the tool's complexity (initialization-focused with parameters controlling output detail), no annotations, and no output schema, the description is fairly complete. It covers the purpose, components, usage context, and hints at behavioral aspects like token usage. However, it could be more complete by specifying the exact format of the returned context or error scenarios, but it's adequate for a read-only tool.
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 100%, so the input schema already fully documents the two parameters (compact and include_snapshot) with clear descriptions. The description does not add any meaning beyond what the schema provides, such as explaining why these parameters matter or their impact on initialization. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 specifies the resource 'compact context dump of the WordPress site' with detailed components listed (focus mode, available tools, active role, etc.). It explicitly distinguishes this tool from siblings by noting it's 'Designed for AI agent initialization,' suggesting it's for setup rather than ongoing operations like wpnav_execute or wpnav_search_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 for when to use this tool ('Designed for AI agent initialization'), indicating it's for initial setup. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools (e.g., wpnav_describe_tools might overlap), so it lacks full exclusion 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the prerequisite steps (discovery and schema retrieval) and the tool's role as an execution endpoint, which adds useful context. However, it lacks details on error handling, authentication needs, rate limits, or what happens during execution, leaving gaps for a tool that performs arbitrary operations.
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 that are front-loaded with the core purpose and followed by essential usage guidance. Every sentence earns its place by providing critical information without redundancy, making it highly efficient and well-structured.
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 complexity of executing arbitrary tools, no annotations, and no output schema, the description is partially complete. It covers prerequisites and basic usage but lacks details on execution behavior, error responses, or security implications. This leaves significant gaps for an agent to understand the full context of using this tool.
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 100%, so the schema already documents both parameters thoroughly. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain how 'arguments' should be structured or validated). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('execute') and resource ('any WP Navigator tool by name'), making the purpose specific. It distinguishes this tool from its siblings by explaining its role as the execution endpoint after using wpnav_search_tools and wpnav_describe_tools for discovery and schema retrieval.
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 guidance on when to use this tool: after discovering tools with wpnav_search_tools and getting their schemas with wpnav_describe_tools. It names specific alternatives (the sibling tools) and implies that this tool should not be used without prior discovery, offering clear context for 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?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get') but does not disclose behavioral traits like rate limits, authentication requirements, or response format. While it hints at the tool's exploratory nature, it lacks details on what 'capabilities' or 'hints' entail, leaving gaps in 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 front-loaded with the core purpose in the first sentence and follows with a clear usage guideline. Both sentences are essential, with no wasted words, making it efficient and well-structured for an agent to parse quickly.
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 complexity as an introspection endpoint with no annotations or output schema, the description is incomplete. It mentions what information is retrieved but does not explain the format or structure of the returned data (e.g., JSON object, list of capabilities), which could hinder the agent's ability to interpret results effectively.
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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage, which aligns with the baseline for tools without 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 clearly states the specific action ('Get') and the resource ('WP Navigator Pro API capabilities, policy configuration, and environment hints'), distinguishing it from siblings like wpnav_execute or wpnav_search_tools. It explicitly mentions what information is retrieved, 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 Guidelines5/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 this tool: 'Call this first to understand what the API can do.' This directly advises the agent to invoke it before other tools, offering clear context for its role in the workflow.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool's purpose (retrieving schemas) and its role in a sequence (post-search, pre-execute), which is useful behavioral context. However, it doesn't mention potential limitations like rate limits, error handling, or response format details, leaving some behavioral aspects unspecified.
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 and followed by usage guidance. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse for an AI agent.
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 (1 parameter, no output schema, no annotations), the description is largely complete: it explains the purpose, workflow context, and usage sequence. However, it lacks details on what the schemas contain or how to interpret them, which could be helpful for an agent. The absence of an output schema means the description doesn't cover return values, but this is acceptable as it's not required to do so.
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 100%, so the schema fully documents the single parameter 'tools' (an array of strings with a max of 10 items). The description adds no additional parameter semantics beyond what's in the schema, such as examples or usage nuances, but this is acceptable given the high schema coverage, resulting in the baseline score of 3.
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 specific action ('Get full input schemas') and target resource ('specific WP Navigator tools'), distinguishing it from siblings like wpnav_search_tools (which searches for tools) and wpnav_execute (which executes tools). It explicitly names the verb and resource with precision.
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 guidance on when to use this tool ('Call this after using wpnav_search_tools') and why ('to get the schemas you need before calling wpnav_execute'), clearly positioning it in the workflow relative to alternatives. It specifies the prerequisite (wpnav_search_tools) and the follow-up action (wpnav_execute).
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 annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a search/discovery tool (implied read-only), returns limited information ('tool names and brief descriptions only'), and references a follow-up action (wpnav_describe_tools). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, which would be helpful for a tool with no 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 two sentences, front-loaded with the core purpose, followed by a crucial usage guideline. Every word earns its place—there's no redundancy or fluff, making it highly efficient and easy to parse.
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 (search with 3 parameters), no annotations, and no output schema, the description does well by clarifying the limited return format and pointing to wpnav_describe_tools for full details. However, it could be more complete by hinting at the output structure (e.g., list of objects with name/description fields) or common use cases, which would help the agent anticipate results.
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 100%, so the schema fully documents all three parameters (query, category, limit). The description adds no additional parameter semantics beyond what's in the schema, such as search algorithm details or category descriptions. Baseline 3 is appropriate when the schema does all the work.
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 explicitly states the verb 'Find' and resource 'WP Navigator tools', specifies the search methods ('by natural language query or category'), and distinguishes it from sibling wpnav_describe_tools by clarifying it returns 'tool names and brief descriptions only (not full schemas)'. This is specific and clearly differentiates from alternatives.
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 guidance on when to use this tool ('Find WP Navigator tools by natural language query or category') and when to use an alternative ('Use wpnav_describe_tools to get full schemas for tools you want to use'). It clearly directs the agent to this tool for discovery and the sibling for detailed schema retrieval.
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:

[![wp-navigator-mcp MCP server](https://glama.ai/mcp/servers/littlebearapps/wp-navigator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/littlebearapps/wp-navigator-mcp)

Score Badge

Copy to your README.md:

[![wp-navigator-mcp MCP server](https://glama.ai/mcp/servers/littlebearapps/wp-navigator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/littlebearapps/wp-navigator-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/littlebearapps/wp-navigator-mcp'

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