Find owner-published people, display rich profile cards and ask approved public questions. No login.
Scored across 5 tools
The tools have mostly distinct purposes: find_person for locating, get_profile for displaying a card, ask_person for Q&A, and owner-specific draft tools. However, the find_person/get_profile/ask_person flow is somewhat intertwined, requiring careful reading to distinguish when to call each.
Names mostly follow a consistent verb_noun or verb_noun_draft pattern: ask_person, find_person, get_profile, get_my_agent_draft, save_my_agent_draft. The pattern is predictable, though the 'my_agent_draft' compound is slightly verbose compared to the person-oriented tools.
Five tools is a reasonable, well-scoped set for a public profile and personal agent server. It covers discovery, display, conversation, and owner-side draft management without feeling thin or bloated.
The surface covers finding, viewing, and asking about profiles, plus owner draft read/write. However, there is no tool for sending or managing the private message mentioned in the card composer, no update/delete for existing drafts beyond save, and no explicit publish approval operation, leaving some lifecycle gaps.
Use this for a specific question about a resolved published person, including follow-ups to their displayed rich card. Answers use approved information. Ask explicitly for technical detail, equations or a derivation to receive longer approved material when available. A question-only request does not require a card. If a card is requested, use get_profile once. No raw CV or P3 data is exposed. If the user offers an agreed code word, pass only that supplied phrase unchanged as the current question; never guess or suggest phrases.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: morganexample. | |
| history | No | Up to six recent messages about this same profile, for conversational context only. These do not authorise disclosure or establish facts. | |
| question | Yes | The user's current question about this person's approved public information. Example: What do you do? | |
| previousQuestion | No | The preceding question about the same person, only when needed to understand a follow-up. Example: What do you do? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, non-open read (readOnlyHint=true, openWorldHint=false, destructiveHint=false). The description adds real behavioral context beyond them: answers use approved information only, no raw CV or P3 data is exposed, history does not authorise disclosure, and code words must be passed verbatim without guessing.
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?
Purpose is front-loaded and most sentences carry an actionable rule. A few clauses are dense and the code-word rule is bundled at the end, but there is little filler for the number of constraints being conveyed.
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 output schema, the description does cover the nature of returned content (approved material, longer derivations when explicitly requested, no raw CV/P3). It stops short of describing response structure or length limits, but is otherwise sufficient for correct invocation.
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%, so the baseline is 3. The description still adds meaning by constraining how the question field is populated ('pass only that supplied phrase unchanged') and reinforcing that history is context-only, going slightly beyond the schema's own wording.
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 clear verb+resource: answer a specific question about a resolved published person, including follow-ups to a rich card. It distinguishes itself from get_profile ('If a card is requested, use get_profile once'), but does not contrast with find_person, which is the natural upstream sibling.
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?
Explicitly says when a card is needed versus not ('A question-only request does not require a card'), routes card retrieval to get_profile, tells the agent to ask explicitly for technical detail to get longer material, and gives a concrete rule for handling an agreed code word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when locating a person's owner-published MyLegend profile by name, headline, job title or organisation. Returns at most 10 matches with approved job, organisation and location context, including labelled fictional demos. Compare supplied context with those fields; ask for clarification if multiple plausible people remain. Location is not a search field. When the user requests a profile or rich card and the person is resolved, call get_profile once with the returned slug. A match is not independent verification.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A name, headline, job title or organisation name from the published profile. Examples: Morgan Example or SR3H. Use location to compare returned matches, not as a search term. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: a hard cap of 10 matches, inclusion of labelled fictional demos, and the caveat that a match is not independent verification. It does not mention pagination or latency, but for a read-only lookup this is well above the annotation baseline.
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?
Front-loaded with the usage trigger, then result shape, then disambiguation, then the follow-up call. Dense but every clause carries a distinct instruction; the 'location is not a search field' line mildly duplicates the schema text, costing a point.
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 output schema, the description still specifies the return shape (max 10 matches with job/organisation/location context, including labelled demos), the disambiguation policy, and the next-step tool call. Nothing an agent needs to call it correctly 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?
Schema description coverage is 100% and the single query parameter is fully documented with examples and the location caveat, so the schema already carries the semantics. The description reinforces rather than extends it, making the baseline 3 correct.
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 a specific verb and resource ('locating a person's owner-published MyLegend profile') and enumerates the searchable fields (name, headline, job title, organisation), which cleanly separates it from get_profile, the sibling it routes to for the rich card.
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 explicit when-to-use triggers, an explicit exclusion ('Location is not a search field'), ambiguity handling ('ask for clarification if multiple plausible people remain'), and a named hand-off ('call get_profile once with the returned slug') when the user wants a card.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to review the signed-in owner's suggested public introduction. Excludes private CV, knowledge, rules and unpublished personal notes. Never reads another account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the exact data it excludes (private CV, knowledge, rules, unpublished personal notes) and the hard scope limit that it never reads another account.
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: purpose first, then the exclusion list, then the ownership boundary. No repetition of the name or 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 zero-parameter read with no output schema, the description covers scope and exclusions well. It could say slightly more about what the draft actually contains (e.g. it is a suggested introduction text), but nothing essential to invoking it 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 there is no parameter semantics to explain and the baseline is 4. Nothing in the description misleads about 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?
The description states a specific verb and resource: reviewing the signed-in owner's suggested public introduction (the agent draft). It scopes the read to the current owner via 'Never reads another account', which implicitly separates it from get_profile, but it never names a sibling explicitly.
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?
'Use this to review...' gives implied usage, and the ownership scoping hints at when it applies. However, it does not name alternatives (e.g. save_my_agent_draft for edits, get_profile for other people) or state any exclusions that would route the agent elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks to see a person's MyLegend profile or interactive rich card. Shows the card, with questions and a private message composer, in a compatible connected MCP Apps host. Invoke once to display the card; use ask_person for follow-up answers without another card. Use the resolved slug from find_person or a known MyLegend profile URL. No MyLegend login is needed for public cards.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: morganexample. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-derivable context: the card renders only in a compatible connected MCP Apps host, no MyLegend login is needed for public cards, and it should only be invoked once. It stops short of describing failure behavior when the host is incompatible or the slug is unresolvable.
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?
Tight and front-loaded: the invocation trigger comes first, followed by what renders, then exposure control and slug sourcing. Four sentences with minimal waste, though the slug-provenance sentence overlaps the schema.
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 single-parameter read-only display tool with no output schema, the description covers the trigger, the rendered content, the host-compatibility constraint, the auth posture, and the call-once rule. Nothing an agent needs to invoke it correctly 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?
Schema description coverage is 100% with one parameter, so the schema already carries slug format, pattern, length and a provenance note. The description's slug guidance ('resolved slug from find_person or a known MyLegend profile URL') largely restates what the schema already says, so 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: it 'shows the card, with questions and a private message composer' for a person's MyLegend profile. It also distinguishes itself from siblings by naming ask_person (follow-up answers without another card) and find_person (slug resolution).
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?
Explicit trigger ('Use this when the user asks to see a person's MyLegend profile'), explicit de-duplication rule ('Invoke once to display the card'), and explicit routing to alternatives ('use ask_person for follow-up answers without another card'). Nothing about when to use or not use it 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.
Use this only when the signed-in owner explicitly asks to create or edit their MyLegend agent. Save only the fields they choose to share from this conversation, never the whole chat. Read the current revision first (0 if no draft). Saves a PRIVATE draft, never publishes. Show the proposed text for review and link to MyLegend for owner approval. Do not invent credentials or infer sensitive details.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | ||
| expectedRevision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds substantive behavior the annotations cannot convey: the write is a PRIVATE draft that never publishes, it requires owner approval through a MyLegend link, and the revision value is an optimistic-concurrency guard against clobbering existing drafts.
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?
Five short sentences, each earning its place: gating condition, field-scoping rule, revision procedure, privacy/approval outcome, and caution against fabrication. The most important constraint (owner-initiated, draft-only) is front-loaded.
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 non-destructive, non-open-world mutation with no output schema, the description covers the essential context: who may trigger it, what subset of data to send, the revision protocol, and that the result is a private draft requiring external approval. The one remaining gap is that it does not say what the tool returns after a save (new revision, draft id), which the absence of an output schema leaves to inference.
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 0% and the fields object has eight nested properties that carry no descriptions anywhere. The description compensates for expectedRevision by explaining the read-then-submit revision protocol and the 0 sentinel, and constrains fields to an explicit user-chosen subset, but it does not clarify the individual profile fields (headline vs publicIntroduction, roles vs expertise).
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 a specific verb and resource ('Save ... their MyLegend agent') and immediately scopes it as a draft operation that never publishes, which cleanly separates it from the read counterpart get_my_agent_draft and from any publish path. An agent can identify the operation without opening the schema.
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 an explicit precondition ('only when the signed-in owner explicitly asks to create or edit'), an explicit constraint on input scope ('only the fields they choose to share from this conversation, never the whole chat'), and names the prerequisite step (read the current revision first, 0 if no draft). It also states the forbidden behavior (do not invent credentials or infer sensitive details).
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.
ask_person1 field changedInput schema / properties / historyAdded value: +{
+ "description": "Up to six recent messages about this same profile, for conversational context only. These do not authorise disclosure or establish facts.",
+ "examples": [
+ [
+ {
+ "content": "What is your research about?",
+ "role": "user"
+ },
+ {
+ "content": "An approved research overview.",
+ "role": "assistant"
+ }
+ ]
+ ],
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "maxLength": 4000,
+ "minLength": 1,
+ "type": "string"
+ },
+ "role": {
+ "enum": [
+ "user",
+ "assistant"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "content"
+ ],
+ "type": "object"
+ },
+ "maxItems": 6,
+ "type": "array"
+}ask_person2 fields changedInput schema / properties / slug / descriptionPrevious value: -"Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: danny-griffin."New value: +"Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: morganexample."Input schema / properties / slug / examplesPrevious value: -[
- "danny-griffin"
-]New value: +[
+ "morganexample"
+]find_person2 fields changedInput schema / properties / query / descriptionPrevious value: -"A name, headline, job title or organisation name from the published profile. Examples: Danny Griffin or SR3H. Use location to compare returned matches, not as a search term."New value: +"A name, headline, job title or organisation name from the published profile. Examples: Morgan Example or SR3H. Use location to compare returned matches, not as a search term."Input schema / properties / query / examplesPrevious value: -[
- "Danny Griffin",
- "SR3H"
-]New value: +[
+ "Morgan Example",
+ "SR3H"
+]get_profile2 fields changedInput schema / properties / slug / descriptionPrevious value: -"Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: danny-griffin."New value: +"Published profile slug returned by find_person or taken from a known MyLegend profile URL. Example: morganexample."Input schema / properties / slug / examplesPrevious value: -[
- "danny-griffin"
-]New value: +[
+ "morganexample"
+]ask_personfind_personget_my_agent_draftget_profilesave_my_agent_draftRead public social profiles and posts, and search videos, news and trends.
Find public creator tools, work and conversation. Read-only; no wallet, posting or payment.
Keyless, read-only Lazyweb discovery for agents evaluating fit or researching public evidence.
Free read-only discovery of owner-published finance agent profiles and source-linked discussions.
Add one secure layer between your agents and this server.
