Give your AI a network of real people.
Marcel is an MCP server that lets your AI find and connect you with people who can help.
Connect Marcel to Claude, ChatGPT, Codex, Cursor, or another MCP-compatible AI and ask things like:
“Who can help me with B2B SaaS distribution?” “Find someone who has hired a customer success team.” “Do I have any new connection requests?”
Marcel uses your profile and network to find relevant people and explain why an introduction makes sense.
No social feed. No f
Scored across 5 tools
Each tool targets a distinct action: delete, export, get, guide, update. The only potential confusion is between get_profile and get_profile_guide, but their descriptions clearly separate data retrieval from instructional guidance.
All tool names follow a consistent snake_case verb_noun pattern: delete_account, export_my_data, get_profile, get_profile_guide, update_profile. The convention is predictable throughout.
Five tools are well-scoped for a personal profile and account management server. Each tool covers a distinct lifecycle operation without redundancy or extreme thinness.
The surface covers the full profile lifecycle: guidance, retrieval, update (including initial creation), export, and account deletion. No obvious CRUD or lifecycle gaps exist for the stated purpose.
Deletes the person's account and everything in it. There is no undo. Only use it when the person asks to leave. Call it first without confirm to get the warning, and read it out. Call it again with confirm set to true only after they clearly say yes.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | true only after the person has confirmed, in their own words, that they want everything deleted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the irreversible consequence ('There is no undo') and, more importantly, the required confirm/warn/confirm workflow, which is behavioral detail not present in any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences ordered by importance: consequence first, eligibility second, invocation sequence third. Every sentence changes agent behavior; none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, single-param mutation with no output schema and annotations that already cover the safety profile, the description supplies everything the agent needs: irreversibility, permission condition, and the exact call sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema itself ('true only after the person has confirmed, in their own words'). The description restates the same gating condition rather than adding new semantics such as what a false/omitted value returns, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource and qualifies scope ('the person's account and everything in it'), so an agent knows exactly what is destroyed. It does not, however, distinguish itself from relevant siblings such as export_my_data or update_profile, which is the one thing keeping this from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('Only use it when the person asks to leave') and a precise two-step invocation protocol: call without confirm to retrieve and read out the warning, then call again with confirm=true only after a clear yes. Nothing 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.
Gives a full copy of what Marcel has about the person. Use it when they ask what Marcel knows. Explain it in simple words.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a presentation directive ('Explain it in simple words') that guides the agent's response tone, but says nothing about the form or scope of the export (file vs. inline data, completeness guarantees).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero padding, with the core purpose front-loaded before the usage trigger. The trailing styling instruction is minor but marginally tangential to invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, non-destructive read tool with annotations covering the safety profile and no output schema, the description is nearly sufficient. It could state what the export actually returns, but nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly implies no caller-supplied input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('gives a full copy of what Marcel has about the person'), which clearly distinguishes an export from the sibling get_profile by emphasizing a complete copy rather than a profile view. It stops short of explicitly naming that sibling, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear triggering condition: 'Use it when they ask what Marcel knows.' No exclusions or alternative tools are named, but the when-to-use context is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows the person's profile, how complete it is, what to add next, their waitlist number, and their share link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description contributes beyond that by revealing the returned payload (completeness score, next steps, waitlist number, share link), which is genuinely useful, but it says nothing about auth/identity assumptions or refresh behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that enumerates the return payload with no filler or restatement of the title. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of explaining what is returned, and it does so adequately. The only gap is the absence of any distinction from the adjacent get_profile_guide tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly does not waste words inventing inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb + resource ('Shows the person's profile') and enumerates the payload (completeness, next steps, waitlist number, share link), so the agent knows exactly what comes back. It does not, however, distinguish itself from the sibling get_profile_guide, which an agent must disambiguate by name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus update_profile or get_profile_guide, nor any prerequisites. The name and content imply a read of the current user's profile, but the routing guidance is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here. It tells you what to ask and how to say it. Read it before you ask the person anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds that this is a prerequisite read before asking questions, which is useful invocation-order context, but it does not disclose return format, length, or other behavioral traits beyond what annotations and the name imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three very short sentences, front-loaded with the key directive 'Start here.' Every sentence contributes to guiding use. Slight redundancy between 'what to ask and how to say it' and 'before you ask the person anything' keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only guide retrieval with no output schema, the description gives enough to call it correctly: it says what the guide contains and mandates reading it before asking the person anything. It does not clarify the guide's exact scope or output form further, but the name and title fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema is fully specified. Per the rule, a 0-parameter tool gets a baseline of 4; the description appropriately does not need to explain parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the guide provides ('what to ask and how to say it') and its role as a starting point, which distinguishes it from the CRUD siblings (get_profile, update_profile, delete_account, export_my_data). It does not explicitly say 'returns a profile guide,' but the name and title carry that, and the description's content is specific enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use guidance: 'Start here' and 'Read it before you ask the person anything.' No alternatives are named, but the sibling tools are unrelated account/profile operations, so no alternative routing is needed. No when-not condition is provided, keeping it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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". |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
delete_accountexport_my_dataget_profileget_profile_guideupdate_profile
Add one secure layer between your agents and this server.