Marcel

Update profile

update_profile

Idempotent

Saves the person's profile. The first save needs the basics. Later saves send only what changed. A list you send replaces the old list.

Input Schema

TableJSON Schema

Name	Required	Description
`why`	No	Why the work matters to them, in their own words, one or two sentences. Optional. The question is: Why do you care about it?
`name`	No	How you want to be known, for example Maya.
`role`	No	What you do now, for example Founder or Staff Engineer.
`links`	No	Where people can see their work.
`proof`	No	One to five things they have actually done that make the help credible: shipped X, hired Y, raised Z, taught W.
`hiring`	No	Set when the person is hiring, whatever their persona. Like LinkedIn's "Hiring" badge. null to clear it.
`openTo`	No	What they are open to.
`canHelp`	No	Specific help they can give, with the context that makes them good at it. Two sentences at least.
`company`	No	Company or project name. Leave empty if you prefer.
`details`	No	Persona-specific answers. Must include persona, matching the top-level persona, plus that persona's fields. See get_profile_guide for the fields per persona.
`persona`	No	What the person does, from their current title. See get_profile_guide interview.personaFromTitle. other only when nothing fits.
`capacity`	No	How much time they can give to conversations.
`headline`	No	One line that sums them up, as on LinkedIn. Optional; write it from role and workingOn and confirm it if they have none.
`location`	No	Where they are based. Ask for the city; look up country, countryCode (ISO alpha-2) and coordinates yourself. Never ask a person for coordinates.
`pronouns`	No	How they like to be referred to, for example "she/her" or "they/them". Optional. Ask once, lightly, and accept "rather not say" as empty.
`timezone`	No	IANA timezone, for example Asia/Kolkata. Derive it from the city.
`username`	No	Public handle others see. Lowercase letters, numbers, underscores.
`education`	No	Up to 5 entries, also from LinkedIn when available.
`interests`	No	Up to five things they are into outside work, in their words: "trail running", "chess", "Tamil cinema". Optional. Shown on their profile so an introduction has something human to start from.
`languages`	No	Languages they are comfortable talking about work in.
`needsHelp`	No	Specific help they are looking for right now, not in general. Two sentences at least.
`workingOn`	No	What they are working on right now, one or two sentences, specific.
`askMeAbout`	No	Three to five short phrases people can ask them about, for example "pricing for dev tools". Shown in search results.
`experience`	No	Work history, most recent first, up to 15 entries. Fill it from a LinkedIn PDF when the person shares one: map each position to an entry. Skip contact details, recommendations and skills sections.
`helpTopics`	No	Skills they can help with. Prefer these: product_strategy, product_feedback, user_research, design_ux, engineering, architecture, devops, ai_ml, data, security, mobile, frontend, backend, go_to_market, distribution, sales, enterprise_sales, marketing, content, seo, paid_ads, positioning, pricing, fundraising, investors, hiring, recruiting, interviewing, leadership, operations, finance, legal, customer_success, support, partnerships, customer_intros, supplier_intros, community, speaking, career_coaching, mentoring, immigration. One custom tag is fine.
`industries`	No	The sectors they work in. Prefer these: devtools, ai, b2b_saas, consumer, marketplaces, fintech, healthtech, climate, ecommerce, hardware, edtech, real_estate, insurance, logistics, media, agencies, nonprofit, open_source, gaming, travel, hr_tech, legal_tech, govtech. One custom tag is fine.
`introStyle`	No	How they like to meet new people.
`openToWork`	No	Set when the person is looking for a role, whatever their persona. Like LinkedIn's "Open to work". null to clear it.
`visibility`	No	Discoverable lets other members find them. Private keeps the profile off search.
`needsTopics`	No	Skills they need help with. Prefer these: product_strategy, product_feedback, user_research, design_ux, engineering, architecture, devops, ai_ml, data, security, mobile, frontend, backend, go_to_market, distribution, sales, enterprise_sales, marketing, content, seo, paid_ads, positioning, pricing, fundraising, investors, hiring, recruiting, interviewing, leadership, operations, finance, legal, customer_success, support, partnerships, customer_intros, supplier_intros, community, speaking, career_coaching, mentoring, immigration. One custom tag is fine.
`ageConfirmed`	No	Marcel is for people 18 or over. Ask "Are you 18 or older?" once before the first save. Only ever send true. If they are not, do not create a profile and tell them Marcel is for adults.
`responseTime`	No	How quickly they usually reply to a new introduction.
`availabilityNote`	No	Optional. When they are usually free, in their words, for example "evenings after 7pm".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true and destructive=false, so the safety profile is covered. The description adds a genuinely non-obvious behavior: arrays are replaced wholesale rather than merged, which is the most likely source of silent data loss and is not stated in the schema or annotations.

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

Conciseness5/5

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

Three short sentences, each earning its place, with the incremental-save expectation front-loaded and the replacement caveat last. No filler and no restatement of the tool title.

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

Completeness3/5

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

For a 33-parameter nested mutation tool the description is light, but the schema is exhaustive and annotations cover the mutation profile. It omits identity/auth context (whose profile is written, whether a session is required) and any pointer to get_profile_guide for persona coverage, which are the remaining gaps.

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

Parameters3/5

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

Schema description coverage is 100% across 33 parameters, so the schema carries all field-level semantics. The description adds no parameter-specific meaning of its own; baseline 3 applies when the schema does the heavy lifting.

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 verb+resource are unambiguous ("Saves the person's profile") and the save lifecycle is spelled out. It stops short of differentiating from siblings like get_profile or get_profile_guide, relying on the reader to infer that this is the write path.

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?

It gives clear context on the two modes of use: a first, fuller save versus later incremental saves, plus the partial-update expectation ("send only what changed"). It does not name alternatives or prerequisites such as get_profile_guide, so the guidance is contextual rather than a full routing rule.

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

All Marcel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?