FrontMCP docs

Find the docs version for a project

resolve_version

Read-only

Says which documented FrontMCP version a project should read, and the endpoint that pins it. Pass the project's package.json, its lockfile (package-lock.json, yarn.lock or pnpm-lock.yaml, including relevant importers and all SDK resolutions), or a version range. An unambiguous lockfile identifies an installation; package.json only the range it allows. If several installations exist, select an npm/pnpm workspace or pass an exact installedVersion read from the resolved SDK package. Call it first when you can read the project.

Input Schema

Name	Required	Description
`range`	No	A version or range, like "1.9.4" or "^1.9.0".
`lockfile`	No	The project's lockfile, including the selected importer and all SDK resolutions. A truncated fragment must preserve that context.
`workspace`	No	Workspace/importer path in an npm or pnpm lockfile, for example "." or "packages/api". Required when installations are ambiguous.
`packageJson`	No	The project's package.json, as it is.
`installedVersion`	No	Exact release read from this project's resolved @frontmcp/sdk/package.json. Takes precedence over a shared lockfile; never guess it from a range.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 22, 2026

addedInput schema / properties / installedVersion

Added value: +{
+  "description": "Exact release read from this project's resolved @frontmcp/sdk/package.json. Takes precedence over a shared lockfile; never guess it from a range.",
+  "maxLength": 40,
+  "type": "string"
+}

changedInput schema / properties / lockfile / description

Previous value: -"The project's lockfile, or the lines about @frontmcp/sdk."New value: +"The project's lockfile, including the selected importer and all SDK resolutions. A truncated fragment must preserve that context."

addedInput schema / properties / workspace

Added value: +{
+  "description": "Workspace/importer path in an npm or pnpm lockfile, for example \".\" or \"packages/api\". Required when installations are ambiguous.",
+  "maxLength": 300,
+  "type": "string"
+}

First observedOct 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true; the description supplies the behavior that matters: a lockfile identifies an installation while package.json only gives the allowed range, and installedVersion takes precedence over a shared lockfile and must not be guessed. That precedence and ambiguity handling is real context beyond the annotations.

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 purpose is front-loaded in the first clause and each following sentence carries non-redundant rules about input precedence and ambiguity. It is dense but every sentence earns its place; a slightly tighter phrasing of the workspace/installedVersion rule would make it a 5.

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?

With five optional, fully schema-documented parameters and no output schema, the description covers what an agent needs to pick the right input and resolve ambiguity, and even hints at the return (the pinned endpoint). Missing only a note on what happens when no version can be resolved.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: why lockfile beats package.json, when workspace is required (ambiguous installations), and that installedVersion is authoritative. The only gap is that truncation/context requirements for lockfile are left to the schema.

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?

States a specific verb and resource: it resolves which documented FrontMCP version a project should read, plus the pinning endpoint. That clearly separates it from get_versions (which lists versions) and the other doc-reading siblings, though no sibling is named explicitly.

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?

"Call it first when you can read the project" gives an explicit ordering cue, and the description explains which input to prefer (lockfile vs package.json vs exact installedVersion) when installations are ambiguous. It stops short of stating when to skip this tool and use get_versions instead, so it is not a full when/when-not/alternatives treatment.

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

All FrontMCP docs tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?