Skip to main content
Glama

cv_outline

Returns the complete CV/profile as path:value lines so you can make targeted edits with profile_update and see them live at /me.

Instructions

The whole CV/profile as path: value lines. Use the paths with profile_update to change any line, e.g. experience[0].bullets[1]. The web app at /me shows the result live.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the output format and the read-then-write workflow with profile_update, implying a safe read. It never explicitly states the operation is read-only, says nothing about which profile (master CV vs. other) is returned, and does not mention permissions or size limits.

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?

Three short sentences, front-loaded with the output shape and followed by the actionable editing hint with an inline example. The closing note about the /me live view is mildly tangential but still useful orientation; nothing is bloated.

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?

For a zero-parameter read tool with no output schema, the description supplies the one thing that matters most: the exact format of the returned data and how to consume it. The main gap is sibling differentiation from profile_get and clarity on scope (whole profile vs. master CV).

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 takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The path example it does include documents the return value rather than an input, which is a bonus rather than a requirement.

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?

The description states a specific resource and return shape: the whole CV/profile rendered as `path: value` lines, with a concrete example path. It is clear what the tool produces, but it never distinguishes itself from the sibling profile_get, which an agent could easily assume returns the same profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one clear downstream usage rule -- feed the returned paths into profile_update to edit a line -- which is genuinely actionable. It offers no when-to-use versus profile_get / profile_get_master_cv guidance and no exclusions, so selection among profile-reading siblings is left to inference.

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