Wiki Analytics Specification MCP Server

by paulsham

Overview Schema Related Servers Score Discussions

JavaScript

Local

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: get_event_implementation retrieves full event specs, get_property_details focuses on property definitions, get_related_events finds contextual events, search_events performs searches, and validate_event_payload validates payloads. The descriptions explicitly state when to use each tool, eliminating ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_event_implementation, search_events, validate_event_payload). The verbs are descriptive and aligned with the actions (get, search, validate), making the set predictable and readable.
Tool Count5/5
With 5 tools, this server is well-scoped for wiki analytics specification management. Each tool serves a specific role in event and property handling, from retrieval to validation, without being overly sparse or bloated. The count aligns perfectly with the domain's needs.
Completeness4/5
The tool set covers core workflows comprehensively: retrieving event specs, property details, related events, searching, and payload validation. A minor gap exists in update or creation tools for modifying specifications, but agents can work around this for read-only and validation tasks in the analytics domain.
Average 3.1/5 across 5 of 5 tools scored.
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
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

Behavior2/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 states the tool finds related events but does not describe how results are returned (e.g., format, pagination), any limitations (e.g., rate limits, access controls), or side effects. This leaves significant gaps in understanding the tool's behavior beyond its basic function.
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, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, with every part contributing to understanding the purpose, making it appropriately sized and well-structured.
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 has no annotations and no output schema, the description is incomplete. It lacks details on return values, behavioral traits, or usage context, which are critical for a tool that likely returns a list of events. The description does not compensate for these gaps, making it insufficient for full 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?
The input schema has 100% description coverage, with the single parameter 'event_name' documented as 'Name of the event to find related events for'. The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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 purpose with a specific verb ('Find') and resource ('events'), specifying they are related through being in the same table/flow as a given event. However, it does not explicitly differentiate from sibling tools like 'search_events' or 'get_event_implementation', which might also involve event retrieval, leaving room for ambiguity.
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 provides no guidance on when to use this tool versus alternatives such as 'search_events' or 'get_event_implementation'. It implies usage when needing events related by table/flow, but lacks explicit when/when-not instructions or named alternatives, offering minimal practical direction.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the search functionality but doesn't describe key behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output looks like (e.g., list format, pagination). For a search tool with zero annotation coverage, this is a significant 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral constraints, leaving the agent with insufficient context for effective tool invocation.
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 minimal value beyond the input schema, which has 100% coverage with clear parameter descriptions. It mentions searchable attributes ('name, description, table, or property usage') that map to the parameters, but doesn't provide additional syntax, format details, or usage examples. This meets the baseline for high schema coverage.
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 purpose with specific verbs ('Search for events') and resources ('events'), and identifies searchable attributes ('by name, description, table, or property usage'). However, it doesn't explicitly differentiate from sibling tools like 'get_related_events' or 'validate_event_payload', which might also involve event queries, so it doesn't reach the highest clarity level.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where other tools might be more appropriate, such as using 'get_event_implementation' for detailed event data or 'validate_event_payload' for validation tasks. This leaves the agent without explicit usage direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get'), implying it's likely non-destructive, but doesn't specify permissions, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose ('Get property definition') and adds useful context ('see where it is used across events and property groups'). There is no wasted language, and it's 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.
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 (single parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, usage context, or output. Without annotations or an output schema, the agent has incomplete information about how to interpret results or handle errors.
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 100% description coverage, with the single parameter 'property_name' documented as 'Name of the property to retrieve'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 purpose with a specific verb ('Get') and resource ('property definition'), and specifies what information is retrieved ('see where it is used across events and property groups'). However, it doesn't explicitly differentiate this tool from its sibling tools like 'get_event_implementation' or 'search_events', which might also involve property-related queries.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, nor does it reference sibling tools. The agent must infer usage based solely on the purpose statement.
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 states the tool validates a payload and returns errors, warnings, and valid fields, which covers the basic operation and output. However, it lacks details on error handling, validation rules, performance implications, or any side effects, leaving gaps in transparency for a validation tool.
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, consisting of a single sentence that directly states the tool's function and output. There is no wasted text, but it could be slightly improved by structuring usage hints or examples without sacrificing brevity.
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 (validation with two parameters, no output schema, and no annotations), the description is minimally adequate. It explains what the tool does and its output, but lacks details on error types, validation scope, or integration with sibling tools. Without an output schema, more information on return values would be beneficial, but it meets the basic threshold.
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 100% description coverage, with clear documentation for both parameters ('event_name' and 'payload'). The description adds no additional semantic details beyond what the schema provides, such as format examples or validation criteria. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here.
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 purpose: 'Validate a tracking implementation payload against the event spec.' It specifies the verb (validate) and resource (payload against event spec), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_event_implementation' or 'search_events', which might also involve event-related operations, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, nor does it reference sibling tools like 'get_event_implementation' or 'search_events' for comparison. This leaves the agent without clear usage instructions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'complete event specification with all properties expanded,' which implies a read-only operation, but doesn't address potential behavioral traits like error handling, rate limits, authentication needs, or what 'complete' entails. This leaves significant gaps for a tool with no structured safety hints.
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 and front-loaded, consisting of just two sentences that directly state the purpose and usage without any wasted words. Every sentence earns its place by providing essential information efficiently.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves event specifications. It doesn't explain what 'complete event specification' includes, the return format, or any behavioral aspects like pagination or errors. For a read operation with no structured output, more context is needed to fully guide 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 input schema has 100% description coverage, with the parameter 'event_name' clearly documented as 'Name of the event to retrieve.' The description doesn't add any additional meaning or context beyond this, such as format examples or constraints, so it meets the baseline score 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.
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 purpose with a specific verb ('Get') and resource ('complete event specification with all properties expanded'), making it easy to understand what it does. However, it doesn't explicitly distinguish this from sibling tools like 'get_property_details' or 'get_related_events', which might also retrieve event-related information, so it doesn't reach the highest score.
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 the tool ('Use when implementing tracking code'), which helps guide the agent. However, it doesn't specify when not to use it or name alternatives among the sibling tools, such as when to choose 'search_events' instead, so it lacks explicit exclusions or comparisons.
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

wiki-mcp-analytics-test-1.1.0 MCP server

Copy to your README.md:

[![wiki-mcp-analytics-test-1.1.0 MCP server](https://glama.ai/mcp/servers/paulsham/wiki-mcp-analytics-test-1.1.0/badges/card.svg)](https://glama.ai/mcp/servers/paulsham/wiki-mcp-analytics-test-1.1.0)

Score Badge

Copy to your README.md:

[![wiki-mcp-analytics-test-1.1.0 MCP server](https://glama.ai/mcp/servers/paulsham/wiki-mcp-analytics-test-1.1.0/badges/score.svg)](https://glama.ai/mcp/servers/paulsham/wiki-mcp-analytics-test-1.1.0)

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/paulsham/wiki-mcp-analytics-test-1.1.0'

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