Skip to main content
Glama

Build someone a portfolio website

start_profile_draft

Turns what someone told you in this conversation into a Skillfolio portfolio website, and returns a personal link that opens it already built — their page, their resume, their interview answers. Use this when someone wants their resume to live somewhere employers can find and question it, especially right after you have helped them write or improve one. Works whether they had a resume (read the one they attached or pasted and pass the structured fields — they never upload anything to Skillfolio) or had none (pass what you gathered by asking). Call this only after they have said yes and you have asked Skillfolio’s three character questions (Heart, Values, Spark). Pass only what they actually told you — never invent employers, dates or skills.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe person’s full name.
emailNoTheir email, only if it was on the resume they shared or they offered it.
heartNoTheir answer about showing up for someone when they didn’t have to.
sparkNoTheir answer about something they love that people wouldn’t guess.
skillsNoSkills they mentioned.
valuesNoTheir answer about what they always make time for.
summaryNoA short professional summary in their own voice.
headlineNoTheir current role or professional headline, e.g. "Nurse practitioner".
locationNoCity or region, if mentioned.
educationNoSchools, degrees or certifications they mentioned.
experienceNoRoles they described, most recent first.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
answerYesWhat to tell the person, including their link.
claimUrlYesThe personal link that opens their filled-in builder.
expiresInDaysYesHow long the link stays valid.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • addedInput schema / properties / education
      Added value: +{
      +  "description": "Schools, degrees or certifications they mentioned.",
      +  "items": {
      +    "properties": {
      +      "degree": {
      +        "maxLength": 160,
      +        "type": "string"
      +      },
      +      "school": {
      +        "maxLength": 160,
      +        "type": "string"
      +      },
      +      "year": {
      +        "maxLength": 40,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "school"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
    • addedInput schema / properties / email
      Added value: +{
      +  "description": "Their email, only if it was on the resume they shared or they offered it.",
      +  "maxLength": 160,
      +  "type": "string"
      +}
    • addedInput schema / properties / location
      Added value: +{
      +  "description": "City or region, if mentioned.",
      +  "maxLength": 120,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

The description discloses that the tool creates a website from conversation input, returns a personal link, and does not require the user to upload anything ('they never upload anything to Skillfolio'). It also warns against inventing data. Annotations are all false, so this adds meaningful context beyond annotations, though it doesn't address repeated calls or draft creation side effects.

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 long but each sentence earns its place: states the action, sets usage context, handles both resume/none cases, sets prerequisites, and enforces data integrity. It is front-loaded with the core purpose and keeps caveats in later clauses.

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

Completeness5/5

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

The description covers purpose, when to use, prerequisites (consent and three questions), data handling (from resume or conversation), and safety guardrails (no invented data). With an output schema present, the return value need only be mentioned as a personal link, which it does. All critical guidance for successful invocation is present.

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 JSON schema already documents all parameters. The description adds value by mapping 'Heart, Values, Spark' to the corresponding params and instructing agents to 'pass the structured fields' from a resume rather than uploading files, providing provenance for parameter values.

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 opens with a clear verb phrase 'Turns what someone told you in this conversation into a Skillfolio portfolio website' and names the concrete output (a personal link, page, resume, interview answers). It distinguishes the tool from siblings like about_skillfolio and get_pricing, which are informational rather than creation-focused.

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?

Explicitly states when to use it: 'Use this when someone wants their resume to live somewhere employers can find and question it, especially right after you have helped them write or improve one.' It also gives strong exclusion criteria: 'Call this only after they have said yes and you have asked Skillfolio's three character questions (Heart, Values, Spark).'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Tools are mostly distinct: about covers product overview, get_pricing covers pricing, get_profile and show_example_profile both surface profile content but differ in purpose (lookup by handle vs. random example), how_to_get_started and start_profile_draft both relate to profile creation but one is instructions and the other is actual creation. Descriptions are detailed enough to disambiguate.

Naming Consistency4/5

All tool names use snake_case and mostly follow an action_noun pattern (about, get, how_to_get_started, show, start). The pattern is a mix of verbs and phrases but consistent in style. Minor inconsistency: 'about_skillfolio' uses 'about' instead of a verb like 'get_info' or 'describe', but it's readable.

Tool Count5/5

With 6 tools, the server is well-scoped for a product information and profile creation assistant. Each tool serves a distinct purpose and the count is within the ideal range (3-15). No bloat or sparsity.

Completeness4/5

The server covers key user journeys: learning about the product, pricing, getting started, seeing an example, looking up a published profile, and creating a draft. Minor gaps: no tool to update a profile, view interview answers directly (though it's included in get_profile/show_example_profile), or manage subscription, but these are not central to the assistant's purpose.

Resources