Skip to main content
Glama
crunchtools

mcp-mediawiki-crunchtools

by crunchtools

Get Site Info Tool

get_site_info_tool
Read-only

Retrieve a MediaWiki site's configuration and version details, including wiki name, base URL, and enabled features, to verify setup and compatibility.

Instructions

Get wiki configuration and version info.

Returns: Site info including wiki name, version, base URL, and features

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the returned fields, but because an output schema exists those details are partly redundant, and it does not mention auth requirements, caching, rate limits, or other behavioral traits 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 short and front-loaded: the first sentence states the purpose, and the second lists return contents without unnecessary elaboration. Every sentence contributes to the agent's understanding.

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 no-argument read-only site info tool with an output schema and readOnlyHint, the description gives enough context to select and invoke it correctly. It could be slightly more complete by stating that no arguments are required or when to prefer this over similarly named info tools, but the essential details are present.

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 tool takes zero parameters, so there is no parameter syntax to explain. The baseline for zero parameters is 4, and the description appropriately does not invent parameter details.

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: get wiki configuration and version info. It is clearly distinct from page-oriented siblings such as get_page_tool and list_pages_tool, though it does not explicitly name or differentiate itself from adjacent info tools like get_user_info_tool or get_file_info_tool.

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 saying it returns wiki configuration and version info, so an agent can infer it should be used when site-level metadata is needed. However, it gives no explicit when-to-use guidance, prerequisites, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.