Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tf2-wiki-mcp What are the stats of the Rocket Launcher?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes the Team Fortress Wiki to LLM clients (Claude Desktop, Claude Code, Cursor, VS Code) over stdio.
Not affiliated with Valve Corporation or the Team Fortress Wiki contributors. Team Fortress 2 is a trademark of Valve Corporation. This is unofficial fan tooling.
Gives an LLM live, accurate access to TF2 wiki content so it stops guessing at weapon stats, patch notes, and cosmetic details.
Generic wiki access — search, fetch pages, get summaries, list recent changes.
TF2 domain tools — structured weapon stats, class loadouts, cosmetic lookup, event item lists, patch notes.
Tool | Purpose |
| Full-text search |
| Page content as |
| Lead-section plaintext |
| Section TOC for selective fetching |
| Recently edited pages |
| Parsed weapon infobox → structured stats |
| All weapons in a class's wiki category |
| Cosmetic item infobox params |
| Items added in an update/event |
| Patch notes for a specific update |
Plus: resource tf2wiki://main, prompts analyze_loadout and compare_weapons.
Related MCP server: Wikipedia MCP Server
Requires uv (which manages the Python toolchain for you). Once installed, uvx tf2-wiki-mcp will fetch and run the server on demand — no manual clone needed.
Standard config works in most MCP clients:
{
"mcpServers": {
"tf2-wiki-mcp": {
"command": "uvx",
"args": ["tf2-wiki-mcp"],
"env": {}
}
}
}Add the standard config above to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Restart Claude Desktop. The TF2 wiki tools appear in the tool picker.
claude mcp add tf2-wiki-mcp -- uvx tf2-wiki-mcpAdd to ~/.codex/config.toml:
[mcp_servers.tf2-wiki-mcp]
command = "uvx"
args = ["tf2-wiki-mcp"]See the Codex MCP docs.
Or add the standard config to ~/.cursor/mcp.json.
Add the standard config to your Gemini CLI settings.json per the Gemini CLI MCP guide.
Or via the VS Code CLI:
code --add-mcp '{"name":"tf2-wiki-mcp","command":"uvx","args":["tf2-wiki-mcp"],"env":{}}'See the VS Code MCP guide for details.
Or via the CLI:
code-insiders --add-mcp '{"name":"tf2-wiki-mcp","command":"uvx","args":["tf2-wiki-mcp"],"env":{}}'Or manually:
Open the GitHub Copilot Chat window.
Click the tools icon (🛠️) → + Add Server.
Fill in: Server ID tf2-wiki-mcp, Type stdio, Command uvx, Arguments tf2-wiki-mcp.
Save.
See the Visual Studio MCP docs.
{
"mcpServers": {
"tf2-wiki-mcp": {
"command": "uvx",
"args": ["tf2-wiki-mcp"],
"env": {},
"type": "local",
"tools": ["*"]
}
}
}Add this in repository settings under Copilot → Coding agent. See the Copilot Coding Agent MCP docs.
Run from a local clone instead of PyPI:
git clone https://github.com/yusufaf/tf2-wiki-mcp
cd tf2-wiki-mcp
uv sync --dev
uv run pytest # offline, uses recorded cassettes
uv run pytest --live # also hits the real wikiTo point an MCP client at the local checkout:
{
"mcpServers": {
"tf2-wiki-mcp": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/tf2-wiki-mcp", "tf2-wiki-mcp"]
}
}
}Code: MIT (see LICENSE).
Wiki content: Not redistributed. This project contains zero scraped wiki data. All page content is fetched live from wiki.teamfortress.com at the user's request and returned directly to the user's LLM client — the same posture as a browser extension.
Wiki content is © its respective contributors under Valve's Steam Subscriber Agreement (Game Site terms). Users of this tool are responsible for compliance with Valve's terms. Code license ≠ content license: MIT covers this codebase, not the wiki content it fetches.
Requests to the wiki include a descriptive User-Agent (tf2-wiki-mcp/<version> (https://github.com/yusufaf/tf2-wiki-mcp)) per MediaWiki etiquette and respect maxlag/Retry-After responses.
Don't check in scraped wiki text. Infobox examples for parser tests are fine (short, fair-use-grade fixtures). Full page dumps are not.
Fetch a cosmetic item page and return its infobox params.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only fetch operation, but without annotations, it does not explicitly state the lack of side effects, authentication requirements, rate limits, or what happens if the cosmetic item does not exist. The term 'fetch' suggests safety, but it's not confirmed.
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 a single sentence of 10 words with no fluff. It conveys the core action and output. However, it is too brief and could be expanded to include essential context without sacrificing conciseness.
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?
Despite low complexity (1 param) and an output schema existing, the description fails to provide critical context: it does not explain what 'infobox params' are, how to specify the item name, or any behavioral details. The 0% schema coverage makes this a major gap.
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?
The only parameter 'name' has no description in the schema (0% coverage), and the tool description does not explain what 'name' refers to (e.g., in-game item name, page title, identifier). No examples, constraints, or format hints are provided, leaving the agent to guess.
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 action ('Fetch'), the resource ('cosmetic item page'), and the output ('infobox params'). It distinguishes from sibling tools like get_page by specifying a specific item type. However, it could be more precise about what 'infobox params' entails.
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?
No guidance is provided on when to use this tool versus alternatives like get_page, get_page_summary, or search_wiki. The agent is left to infer that it's for cosmetic items only, but there is no explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single TF2 Wiki page. format picks raw wikitext, plaintext extract, or rendered HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| format | No | plain |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 describes the format options but does not mention read-only behavior, rate limits, or prerequisites. It does not contradict any annotations.
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?
Two concise sentences: the first defines the action, the second explains the most important parameter. No wasted words.
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 output schema exists (return values not needing explanation), the description covers the core function and the key parameter. Could briefly note that the title must be a valid page title, but it is adequate.
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 coverage is 0%, so the description adds significant value by explaining the enum choices for 'format' (wikitext, plain, html). However, 'title' is not elaborated beyond the schema, leaving some gap.
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 'Fetch a single TF2 Wiki page' and explains the format parameter, distinguishing it from siblings like get_page_sections and get_page_summary which target specific parts of a page.
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 implies use when needing a full page in a specific format but does not explicitly state when to use this tool versus alternatives like get_page_sections or get_page_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Section table-of-contents for a page; use before get_page to fetch selectively.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only operation returning a table of contents, but does not disclose details like authentication needs, rate limits, or what happens with invalid titles. The output schema likely covers return structure, so some transparency is deferred.
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 a single 12-word sentence that efficiently states the purpose and usage guidance. There is no wasted text; every word earns its place.
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's simplicity (one string parameter, output schema present) and the context of sibling tools, the description provides sufficient information for an AI agent to understand what the tool does and when to use it. The output schema handles return value documentation, so no further detail is needed.
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?
The schema has 0% description coverage for the parameter 'title', and the tool description does not explain it. However, the parameter name 'title' is self-explanatory (page title), so the baseline is adequate. No additional semantic value is added by the description over the schema's property name.
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 it provides a section table-of-contents for a page, using a specific verb ('table-of-contents') and resource ('page'). It distinguishes itself from the sibling tool get_page by noting it is a precursor for selective fetching.
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 gives explicit guidance to use this tool before get_page for selective fetching, which differentiates it from the sibling. However, it does not explicitly state when not to use it or mention other alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lead-section plaintext summary of a page. Fast context anchor.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions 'plaintext summary' and 'fast', but lacks details on return format (e.g., size limits), error conditions, authentication needs, or any side effects. Significant gaps remain.
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 extremely concise—two short sentences—with no wasted words. It front-loads the key purpose and is efficient for an agent to parse.
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's simplicity (one required parameter, no nesting) and presence of an output schema, the description is minimally adequate. However, it could be improved by noting that the output is plaintext only and that the tool is ideal for quick summaries, but the current level is sufficient for a basic understanding.
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?
The description adds no meaning to the single 'title' parameter beyond what the schema shows. With 0% schema description coverage, the description should clarify expected format, case sensitivity, or valid values, but it does not.
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 returns a 'lead-section plaintext summary' of a page, which differentiates it from sibling tools like 'get_page' (full page) and 'get_page_sections' (all sections). The verb 'get' is implied, and the resource is explicitly identified.
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 phrase 'Fast context anchor' implies quick retrieval, but there is no explicit guidance on when to use this tool versus siblings, nor any when-not-to conditions. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch patch notes for a named update or patch page (e.g. 'October 5, 2023 Patch').
| Name | Required | Description | Default |
|---|---|---|---|
| update_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as error handling, rate limits, or side effects. For a fetch operation, the lack of transparency is a gap.
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 a single, well-structured sentence that conveys the core purpose efficiently without redundancy.
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?
For a tool with one parameter and an output schema, the description covers the basic action but omits details on behavior when the update_name is invalid or the content of the return value.
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?
The description adds meaning to the sole parameter 'update_name' with an example, but does not specify format constraints or where to find valid names. Schema coverage is 0%, so the description partially compensates.
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 uses a specific verb 'Fetch' and resource 'patch notes for a named update or patch page' with an example, clearly distinguishing it from sibling tools like get_page or get_recent_changes.
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 implies usage when needing patch notes for a specific update, but does not explicitly state when to use or not use this tool versus alternatives, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recently edited pages in the given namespace (0 = main/articles).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| namespace | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It only states what the tool does (retrieve recent changes) without mentioning idempotency, side effects, or access restrictions. Minimal disclosure.
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?
Single sentence, no unnecessary words, front-loads the key action and parameter. Highly efficient.
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?
With two optional parameters and an output schema present, the description is adequate but minimal. It lacks details on ordering, pagination, or what the output contains, though the output schema may cover returns. Still, it feels slightly incomplete for a fully self-contained description.
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 0%, but the description explains the namespace parameter's meaning (0=main/articles), adding value beyond the schema. However, the limit parameter is not described, so it only partially compensates for the lack of schema descriptions.
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 retrieves recently edited pages in a given namespace, with a note that namespace 0 is main/articles. It is specific and distinguishes from sibling tools that return different page data.
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?
No guidance on when to use this tool versus alternatives like get_page or search_wiki. The description does not mention exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a weapon page and return structured stats parsed from its infobox.
Returns damage, rate-of-fire, reload, clip size, attributes (+/- effects), etc.
| Name | Required | Description | Default |
|---|---|---|---|
| weapon_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions output fields but fails to disclose behavioral details like error handling, rate limits, or input format constraints.
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?
Two concise sentences front-load the primary purpose and illustrate typical output fields with no unnecessary words.
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?
Adequately describes tool purpose and output, but lacks details on input format and edge cases; output schema exists to compensate for return value description.
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 coverage is 0%; description adds no specifics about the weapon_name parameter (e.g., case sensitivity, exact match requirements) beyond the schema.
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?
Clearly states it fetches a weapon page and returns structured stats from its infobox, distinguishing itself from generic page retrieval siblings like get_page.
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?
Implied usage for weapon stats, but no explicit guidance on when to use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all weapons for the given class.
Intersects Category: with Category:Weapons on the wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It mentions a simple intersection query, but does not disclose output shape, authentication needs, rate limits, or any side effects. The behavioral insight is minimal.
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 only two sentences, both front-loaded with the core purpose and method. No extraneous information or redundancy.
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 simplicity (1 param, output schema exists), the description covers purpose and method adequately. However, it lacks usage notes or edge case handling, leaving minor gaps.
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 coverage is 0%, yet the description adds no explanation for the 'class_name' parameter beyond 'given class'. It relies entirely on the enum definition in the schema, providing no additional context or format details.
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 action ('List all weapons') and the resource ('for the given class'). It explains the intersection method, which distinguishes it from siblings like get_weapon_stats or list_event_items.
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 implies usage for listing class weapons but provides no explicit guidance on when to use this tool versus alternatives like get_weapon_stats for stats, or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List items added during a given TF2 event/update (e.g. 'Jungle Inferno Update', 'Smissmas 2023').
| Name | Required | Description | Default |
|---|---|---|---|
| event_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of behavioral traits such as read-only nature, error handling, or limits. It merely states the action without elaborating on side effects or expectations.
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 a single sentence, concise and to the point. It lacks structural elements like bullet points or parameter details but is efficient for a simple tool with one parameter.
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 one required parameter and an output schema exists, the description is minimally adequate. However, it does not mention what the output contains or handle edge cases like invalid event names, which could be improved.
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?
The schema has 0% description coverage for the parameter, but the description adds meaning by specifying that event_name refers to a TF2 event/update with concrete examples. However, it does not specify format, case sensitivity, or valid values, leaving gaps.
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 lists items added during a given TF2 event/update, with specific examples like 'Jungle Inferno Update'. This distinguishes it from sibling tools like get_cosmetic or search_wiki, which serve different purposes.
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 implies usage by providing examples but does not explicitly state when to use versus alternatives, nor does it mention prerequisites or exclusions. Sibling tools are not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search the TF2 Wiki. Returns title + snippet + wordcount for each hit.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It discloses return fields but does not mention pagination, rate limits, read-only nature, or search behavior (exact vs fuzzy). Insufficient for a search tool.
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?
Single sentence with no waste. Front-loaded purpose and return fields. Highly concise.
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 2 params, no enums, and output schema present, the description is adequate but lacks details on search mechanics (e.g., fuzzy matching, snippet truncation). Output schema may cover return structure, but behavior still under-specified.
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 0%. The description does not explain 'query' or 'limit' beyond the schema types. It implies query is search term but lacks explicit semantics. No added value over schema.
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 verb 'search', resource 'TF2 Wiki', and returns 'title + snippet + wordcount'. It distinguishes from siblings like 'get_page' which retrieves a specific page.
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 implies use for full-text search when exact page is unknown, but provides no explicit when-to-use, when-not-to-use, or alternatives among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1get_cosmeticget_pageget_page_sectionsget_page_summaryget_patch_notesget_recent_changesget_weapon_statslist_class_loadoutlist_event_itemssearch_wikiScored across 10 tools
Each tool targets a distinct aspect of the TF2 Wiki: generic page retrieval, specific item stats, patch notes, search, and listing tools. No two tools have overlapping purposes, so an agent can clearly distinguish them.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_, list_, search_). No mixed conventions or vague verbs, making the naming predictable.
10 tools is well-scoped for a wiki server. It covers page fetching, specific data extraction, search, and listing without being overwhelming or incomplete.
The tool set covers core wiki operations: reading pages (full, sections, summary), searching, recent changes, and domain-specific data (cosmetics, weapons, events, class loadouts, patch notes). No obvious gaps for a read-only wiki interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and write your team's shared, AI-readable wiki from any MCP client.
Enable Large Language Model clients to interact seamlessly with any MediaWiki wiki. Perform action…
Wikipedia, Wikidata and Wiktionary as clean JSON, not HTML. 1.9M searchable. Free, no auth.
Live Wikipedia edit feed, page summaries, trending pages, and Wikidata search.
