seo-console-mcp

Overview Schema Source Related Servers Discussions Admin

server_version

Report the actual server build, install location, and npx cache status to clarify which version is truly running versus declared or resolved versions. Read-only check requiring no credentials.

Instructions

Report which build of this server is answering, where it is running from, and whether it came out of an npx cache. Four values look like this one and are not: what npm calls latest, what the version range resolves to, what the plugin manifest declares, and what is actually running. Checking the command-line tool is not a substitute, since it is a separate process resolved separately. No credentials needed; read-only

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`version`	Yes	The version of the build answering this call, which is not necessarily what npm calls latest, what the version range resolves to, or what the plugin manifest declares
`npxCache`	Yes	Whether this build is being served out of an npx cache, which reuses a build without re-resolving the version range and without erroring
`installPath`	Yes	Where this build is running from. An npx cache path is what distinguishes the release you expected from whatever npx already had
`nodeVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.18.0Sep 24, 2026

TDQS

A4.5/5.0

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 of behavioral disclosure. It states the operation is read-only, requires no credentials, and returns four values, and it explains the resolution context (npx cache, separate process). It does not describe the exact output format, but the presence of an output schema reduces the need for that detail.

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 compact and front-loaded with the core purpose, then adds the disambiguation and usage caveat. It is slightly dense and could be split into clearer sentences, but every sentence earns its place and there is no 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 has no parameters, an output schema exists, and the description covers purpose, disambiguation, credentials, and read-only behavior, the description is nearly complete. The only minor gap is not explicitly describing the output structure, but the output schema covers that.

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 has zero parameters, so there is no parameter semantics burden. The description adds meaningful context about what the returned values represent and what they are not, which is more than the empty schema provides. A baseline of 4 is appropriate for a no-parameter tool.

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 tool reports which build of the server is answering, where it runs from, and whether it came from an npx cache. It distinguishes this from four similar-looking values (npm latest, version range resolution, plugin manifest, actually running) and from the command-line tool, so an agent can tell exactly what this tool does and what it does not do.

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 explicitly warns that checking the command-line tool is not a substitute because it is a separate process resolved separately, and it clarifies that no credentials are needed and the operation is read-only. This gives clear when-to-use and when-not-to-use guidance, including an alternative that should not be used.

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