Skip to main content
Glama
vinayvobbili

resume-kit-mcp

by vinayvobbili

show_version

Retrieve the resolved plain-text resume for a specified version, showing what the PDF will contain before you build or review it.

Instructions

The resolved resume as plain text (what the PDF will say).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

D1.8/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits, but it only mentions that the output is plain text. It does not state whether the operation is read-only, what happens if the version does not exist, or any other side effects or requirements. This leaves significant gaps for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a very short single sentence, but it is under-specified rather than appropriately concise. It fails to front-load the action or any essential information. The sentence does not earn its place because it omits key details about what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no annotations, and an output schema, the description is critically incomplete. It does not explain how to invoke the tool, what the version parameter means, or when to use it. The presence of an output schema only covers return values, but the description fails on all other fronts.

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

Parameters1/5

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

The schema has one required parameter 'version' with 0% description coverage, and the description never mentions it. The description says 'The resolved resume' without indicating it takes a version argument. It provides no meaning or format for the parameter, leaving the schema alone to define it.

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

Purpose2/5

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

The description is a noun phrase describing the output ('The resolved resume as plain text') rather than stating what the tool does. It lacks a verb and does not distinguish this tool from siblings like list_versions or build_version. An agent cannot confidently infer the action from this text alone.

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?

There is no guidance on when to use this tool versus alternatives such as list_versions or build_version. The description gives no context, prerequisites, or exclusions. It merely describes the output format without any usage instructions.

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