Skip to main content
Glama
Sign In
MGSV MCP

MGSV MCP

by arsenal-pt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

read_wiki_page

Read-onlyIdempotent

Read indexed MGSV modding documentation pages with line numbers and provenance, paginating until next_line is null.

Instructions

Read any indexed document with line numbers and its own provenance; paginate until next_line is null.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "page": "<page>"
    },
    "name": "read_wiki_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageYes
max_linesNo
start_lineNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description usefully adds that output carries line numbers and provenance and that pagination terminates on a null next_line, but says nothing about size limits or error behaviour.

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?

A single front-loaded sentence with two clauses, no filler. It is tight, though the same sentence is being asked to carry both purpose and pagination guidance.

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?

For a simple read-only tool with no output schema, the description covers the pagination contract but omits any explanation of the three undocumented parameters and return-value detail beyond line numbers and provenance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning and largely fails: it never mentions 'page', 'max_lines' or 'start_line'. The pagination hint implies start_line/max_lines exist but gives no format, valid range, or default semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb ('Read') and resource ('any indexed document') plus the line-number/provenance return shape. However, it never distinguishes itself from near-neighbours like read_workspace_text, search_wiki, or fetch, and 'any indexed document' is broader than the tool's own name, leaving the exact scope fuzzy.

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 only procedural guidance is 'paginate until next_line is null', which describes a loop condition rather than when to choose this tool. No mention of when to prefer it over search_wiki (discovery) or read_workspace_text (local files), and no prerequisites.

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

Deploy Server

Other Tools