agentic-linkedin

by DarkLvrd

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between posts, comments, reactions, messages, connections, profile editing, skills, session management, and voice profile operations. Even similar-sounding tools like react and react_to_message are clearly differentiated by their target.
Naming Consistency3/5
The dominant pattern is snake_case verb_noun (create_post, send_message, get_profile), but there are several bare verbs like comment, react, connect, follow, login, plan, approve, and reject, plus non-verb names like session_status and dry_run. The mixed conventions are still readable and not chaotic, but they are inconsistent enough to prevent a higher score.
Tool Count2/5
39 tools is well beyond the 25-tool threshold where a tool set starts to feel heavy. While the domain is broad—covering posts, messaging, connections, profile management, voice, and approval workflows—the sheer count makes it difficult for an agent to efficiently select among many highly specialized operations.
Completeness4/5
The surface covers core LinkedIn lifecycles well: posts can be created, read, edited, and deleted; messaging has send/recall/history; connections have invite/respond/remove/follow; and profiles support updating, skills management, and endorsements. Minor gaps exist—comments cannot be edited or deleted, reactions cannot be removed, and media/post attachments are unsupported—but these are workable limitations rather than fatal dead ends.
Average 3.5/5 across 39 of 39 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It names the returned data categories but does not explain ordering, scope (own conversations vs all), pagination behavior, or what 'recent' means relative to last activity. The effect of the limit parameter is also not described.
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 a single efficient sentence with no filler, and the core return value is front-loaded. It is concise, though the conciseness comes at the expense of important semantic and behavioral details captured under other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too thin to fully support correct invocation. It mentions only participants and last activity as return attributes, and omits limit semantics, result ordering, conversation scoping, and distinction from get_conversation_history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, limit, with 0% schema description coverage, and the description does not mention it at all. An agent is left only with the schema's min and max constraints and has no context for what limit controls or what the default behavior is.
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 clearly states it returns recent messaging conversations and specifies the key data included: participants and last activity. However, it does not explicitly differentiate itself from the sibling tool get_conversation_history, so an agent could conflate listing conversations with retrieving the contents of a conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_conversation_history or send_message. The description only says what the tool returns, leaving the agent to infer when it should be selected over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It states only the immediate effect and does not disclose whether reactions are idempotent, overwrite existing reactions, require permissions, or return any confirmation.
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 a single sentence with no filler and is front-loaded with the action. It is concise, though the brevity sacrifices useful context that an agent would need for reliable invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and three required parameters, the description is not complete. It omits how to obtain conversationUrn and messageId, what counts as a valid emoji, and what happens on repeat calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for conversationUrn, messageId, or emoji. The agent is left to guess what values are valid, how messageId should be formatted, and whether emoji accepts standard Unicode or specific encoded values.
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 uses a specific verb ('Leaves') and resource ('emoji reaction on a message'), so the core operation is clear. It does not explicitly distinguish itself from sibling tools like 'react', but the message-targeting wording provides enough orientation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or exclusions are provided. The description does not explain when to choose react_to_message over related siblings like 'react', 'comment', or 'send_message'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, but it only states the basic follow/unfollow action. It does not disclose whether the operation is idempotent, whether it requires authentication, or what happens when the target is already followed or unfollowed. This is a noticeable gap for a state-changing tool.
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 a single, front-loaded sentence with no fluff; the action and target types are immediately visible. Small deduction for cryptic jargon ('SDUI', 'Voyager patch') that adds confusion without earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and zero parameter documentation in the description, this one-liner is barely adequate. It omits important context such as urn semantics, idempotency, permission requirements, and expected response behavior, so an agent may need to make unsupported assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, yet it only mentions 'person' and 'company,' which maps to the kind parameter. It does not explain the urn identifier format or clarify the boolean semantics of follow, leaving an agent to infer key input meaning from the schema alone.
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 clearly states the action ('Follows or unfollows') and the resource types ('a person' or 'a company'), so an agent can tell what the tool does. It does not explicitly contrast with sibling tools like connect, but the verb and resource are specific enough to avoid major confusion. The unexplained abbreviations 'SDUI' and 'Voyager patch' slightly reduce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as connect, respond_invitation, or endorse_skill. The only usage cue is implied by the word 'Follows,' with no mention of prerequisites, exclusions, or decision rules for person versus company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention that deletion is 'routed through SDUI,' which is a behavioral trait, but it does not state irreversibility, required permissions, or side effects. For a destructive operation, this is a notable gap.
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 a single, front-loaded sentence with no filler. It is compact and to the point, though it could trade a little compactness for defining 'ghost entry' or 'SDUI.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and no annotations, the definition underspecifies required inputs and behavior. An agent would not be confident about what values to supply for section/urn or what 'SDUI' implies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'section' or 'urn' mean or how they identify the ghost entry. The phrase 'profile entry' offers only a weak domain hint and provides no parameter-level meaning.
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 verb ('Removes') and identifies the resource as 'a profile entry that standard deletes miss,' which helps distinguish it from normal delete operations such as delete_post or remove_skill. However, the terms 'ghost entry' and 'SDUI' are unexplained, leaving some ambiguity about what exactly is being removed.
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?
The phrase 'that standard deletes miss' implies when to use this tool—when ordinary delete operations fail—but it does not name alternatives or state explicit when-not-to-use conditions. The guidance is present but only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency. It only indicates that the action is a mutation ('endorses'), but it does not disclose reversibility, permission requirements, side effects, or what the response will look like.
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?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple tool and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no annotations, and no output schema, the description is too thin. It omits parameter roles, especially vanityName, and provides no behavioral or result context, so an agent may not be able to call it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by making clear that a skill is being endorsed on a profile, which maps to skillId and profileUrn, but the meaning of vanityName is left completely unexplained.
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 the action (endorses) and the object (a skill on someone's profile), so the core purpose is clear. It does not explicitly differentiate this from sibling tools like add_skill or remove_skill, which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus add_skill or other profile-related actions, nor any prerequisites such as whether the target must be a connection. Any usage context must be inferred entirely from the name and the brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It signals a read operation by saying 'Returns', but it omits key behavioral traits such as ordering, pagination, whether recalled or system events are included, and how the optional limit affects results.
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?
One sentence, front-loaded with the operation and resource, with no filler or repeated schema information. Every word contributes to defining the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of return semantics, yet it omits important context such as the effect of limit, ordering, and possible event types. It is adequate enough to guess the main purpose, but not complete enough to call reliably in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the tool description still does not explain conversationUrn or limit. The word 'conversation' is a weak allusion to conversationUrn, but no format, example, or additional semantics are provided beyond what the schema already shows.
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 uses a clear verb ('Returns') and names the resource ('conversation') and the output shape ('events with id, sender, text, sent time'). It does not explicitly differentiate from siblings like get_conversations, but the event-level focus makes the intended purpose recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this over get_conversations, send_message, or other conversation-related siblings. The description states what the tool returns but never says when to use it or which alternatives it should replace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Leaves' implies a mutation, but the description does not mention required permissions, whether the comment is publicly visible, whether it can be edited or removed, or what the response will be.
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 a single, clear sentence with no filler or repetition. It is front-loaded and easy to parse, though it is also terse enough that some behavioral and parameter context is missing.
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 simple two-parameter mutation tool, the description captures the core operation acceptably. However, with no annotations and no output schema, the absence of return-value or effect information leaves the agent without a full picture of what happens after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only adds the concept of a 'text comment on a post', which loosely maps to 'text' and 'postId', but offers no detail about formats, constraints, or how the parameters relate.
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 clearly states the action ('Leaves') and the resource ('a text comment on a post'). It is distinguishable from siblings like 'react' (non-text reaction) and 'create_post' (creating a new post), though it does not name any alternatives explicitly.
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?
The description implies when to use this tool: whenever a text comment needs to be added to a post. However, it provides no explicit guidance about when not to use it or when to prefer a sibling such as 'react' or 'send_message'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states the side effect (reordering) and the return value ('verified skills state'), but it does not clarify whether the reorder is persistent, destructive, or subject to any authorization requirements.
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?
The description is a single, front-loaded sentence that states the operation and the return behavior with no filler. It is appropriately compact for the apparent simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description still leaves important details unexplained: what values belong in 'order', what 'top skills' means, and what 'verified skills state' represents. The description is too sparse to fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the 'order' parameter, but it never states whether the array contains skill IDs, names, or a subset of skills. The tool name and the verb 'reorders' allow some inference, but the exact expected values and format are left ambiguous.
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 uses a clear verb ('reorders') and identifies the resource ('top skills'), while adding a specific ordering rule ('newest first'). It is distinguishable in intent from sibling skills tools like add_skill, remove_skill, and endorse_skill, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool instead of alternatives like add_skill, remove_skill, or endorse_skill. There are no conditions, prerequisites, or exclusion cases to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool mutates the profile by adding a skill and reveals an additional behavioral trait: it 'returns the verified skills state.' However, with no annotations and no further context, the meaning of 'verified' and any side effects are left unclear.
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?
A single efficient sentence that front-loads the action and adds a useful behavioral note about the return value. No filler or redundancy.
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 simple one-parameter tool, the description covers the core action and return behavior. But it lacks usage context, explanation of the verification state, and any behavioral caveats, which matters because no annotations or output schema exist to fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the single 'name' parameter is undocumented. The description indirectly implies that 'name' is the skill to add, but says nothing about format, constraints, uniqueness, or accepted values.
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 clearly states the action ('Adds a skill') and the target resource ('the profile'), making the purpose obvious. It is clear enough to be distinguished from siblings like remove_skill or reorder_skills, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to prefer add_skill over endorse_skill or update_profile, no prerequisites, and no exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that deletion happens 'through SDUI' and that it includes a verification step. However, it omits consequences of failure, permanence of deletion, and any authorization requirements—context an agent would benefit from.
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?
A single concise sentence front-loads the action and adds two meaningful details (SDUI channel and feed verification) without any redundant padding. Every word earns its place.
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 simple one-parameter tool, the description covers the primary action and a notable verification behavior. It leaves gaps around the meaning of 'SDUI,' behavior when the post does not exist, and what the tool returns or reports—missing information for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one postId string with 0% description coverage, and the description does not mention the parameter. Although 'postId' is self-explanatory in the context of 'deletes a post,' the description adds no meaning about its format, source, or constraints, leaving the schema to do all the work.
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?
States a specific verb and resource ('deletes a post') and adds extra precision with 'through SDUI' and 'verifies it no longer appears in the feed.' It does not explicitly name sibling alternatives, but the combination of post and feed distinguishes it from related tools like delete_ghost_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The intended usage is implied by the action itself, but the description does not help route an agent away from similar deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states only that it returns specific fields and 'pending' invitations, but does not explain whether the limit parameter affects pagination or defaults, whether invitations are incoming/outgoing, or any side-effect profile. This is minimal disclosure for a tool with zero annotation support.
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?
The description is a single sentence that is immediately informative, with no filler or redundant wording. It front-loads the core purpose and result shape efficiently.
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 simple read tool with one optional parameter and no output schema, the description covers the basic purpose but omits details an agent might need, such as default limit, result ordering, or connection direction. It is minimally adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The schema provides type and bounds, but the description adds no meaning about what limit controls or how it affects results. With low coverage, the description should compensate but does not.
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 uses a specific verb ('Returns') and names the exact resource ('pending connection invitations') along with the fields returned (id, profile, sent time). It clearly distinguishes this as a read/list operation compared to sibling tools like respond_invitation or connect, though it does not explicitly name them.
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?
The usage intent is implied: call this when you want pending connection invitations. However, there is no explicit guidance on when to use this versus respond_invitation or get_connections_summary, and no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, and it does state the output fields and read-only nature indirectly through 'Returns'. It does not explain ordering, time range for 'recent', pagination, or the effect of the limit parameter, leaving meaningful gaps.
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?
One sentence, front-loaded with the action and resource, with every word contributing value. There is no redundant or filler content.
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 simple read tool with one optional parameter, the description is close to sufficient: it states the resource and return fields. It lacks explicit behavior for limit, default result count, ordering, and whether 'feed' means the current user's feed, so an agent may need to infer some calling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the single 'limit' parameter or clarify how it affects results. The parameter name and min/max bounds provide some information, but the description adds nothing beyond the schema.
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 names a specific action and resource, 'Returns recent feed posts', and lists the returned fields, so an agent can tell it is a read operation for posts. It does not explicitly differentiate it from sibling retrieval tools, but the 'feed posts' scoping is reasonably distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_profile, get_conversations, or create_post. The description only states what it returns, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does state the destructive action ('deletes'), but it omits important behavioral details such as irreversibility, permissions, recipient-visible effects, or whether recall differs from a plain delete.
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?
The description is a single, efficient sentence that front-loads the core action and scope. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description does not cover parameter semantics, preconditions, or expected behavior beyond the basic action. With no annotations and no output schema, this leaves meaningful gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. 'conversationUrn' and 'messageId' are left entirely undocumented, and the description only identifies the general resource without mapping it to the parameters.
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 uses a specific action ('Recalls (deletes)') and a clear resource ('a message you sent'). The qualifier 'you sent' differentiates this from deleting posts or reacting to messages, making it distinguishable from siblings like delete_post and react_to_message.
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?
The description implies usage context by specifying 'a message you sent', which explains when the tool applies. However, it does not explicitly state when not to use it or mention alternative tools for similar actions, leaving this to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the destructive nature of the operation ('Removes') but does not state whether the action is permanent, requires special permissions, or has side effects on related data.
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?
The description is a single, front-loaded sentence with no filler. It adds the useful 'by vanity name' detail beyond the title while remaining perfectly concise.
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 simple one-parameter removal tool, the description provides the core operation and the parameter meaning. However, with no annotations and no output schema, the agent is left without information about irreversibility, side effects, or what a successful removal returns.
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?
The schema provides no description for vanityName, so the description's 'by vanity name' adds necessary meaning and correctly maps to the only parameter. However, it does not clarify what a vanity name looks like or any format constraints, leaving some ambiguity for the agent.
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 clearly states the operation ('Removes') and the resource ('a connection'), and identifies the key used ('vanity name'). It is clear enough to distinguish from sibling tools like connect or get_connections_summary, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus related tools such as connect, respond_invitation, or remove_skill. There is no mention of prerequisites, ownership requirements, or situations where removal would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic search behavior and does not mention return format, result limits, pagination, or whether empty criteria return all jobs. This is minimal coverage of the tool's behavior.
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?
The description is a single sentence with no filler. The resource and all relevant parameters are mentioned front and center, making it highly concise while still communicating the core purpose.
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 simple tool with only two optional string parameters, the description is close to adequate. However, with no output schema and no annotations, it leaves the agent guessing about return values and whether the parameters are required or mutually exclusive.
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 0%, so the description must compensate. It does name both parameters and assigns them a role as search filters ('keywords and location id'), which adds meaning beyond bare string types. However, it omits details such as optionality, format of locationId, and how the filters combine.
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 clearly states the verb ('Searches'), the resource ('jobs'), and the two search criteria ('keywords and location id'). It is not fully distinctive because it doesn't explicitly differentiate from sibling tools, but no sibling appears to offer job search, so the purpose is unambiguous.
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?
The description implies when to use the tool: when searching for jobs by keywords and/or location. It offers no explicit guidance about optionality, required parameters, or exclusions, but the intended use case is reasonably inferable from the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds the behavioral detail 'verified by read-back,' which is useful and goes beyond the schema. But with no annotations provided, the description carries the full burden; it does not disclose side effects, permission requirements, irreversibility, or what the read-back verification entails.
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?
The description is a single front-loaded sentence with no filler. Every phrase earns its place: the action set, the resource, and the read-back verification.
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 simple two-parameter tool with an enum, the core behavior is covered and the read-back detail adds useful context. However, with no output schema and no annotations, the description omits return-value expectations and usage caveats, leaving some gap for an agent deciding whether this is the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It repeats the action enum values but does not explain the 'invitationUrn' parameter's format, ownership, or relationship to the invitation lifecycle. The agent is left to infer most of the parameter's meaning.
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 gives specific verbs ('accepts, ignores, or withdraws') and a concrete resource ('connection invitation'), making the tool's purpose immediately clear. It differentiates from siblings like connect or remove_connection by its unique action set, though it does not explicitly name alternatives.
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?
The description implies the tool is used when a connection invitation needs to be accepted, ignored, or withdrawn. However, it provides no explicit guidance about when not to use it or how it compares to sibling tools such as connect, get_invitations, or remove_connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral implications on its own. It only says 'creates or updates' and lists fields, but does not explain whether updates are partial or full replacements, what gets overwritten, whether userId is required, or what the operation returns.
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?
The description is a single, front-loaded sentence with no filler. It communicates the core action and key parameter domains efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, no output schema, and zero schema descriptions, this description is too sparse. It does not tell the agent how to handle partial updates, which parameters are needed for a valid call beyond userId, or what the result of the operation looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate for all 8 parameters. It names several parameter categories (tone, vocabulary, emoji, sentence length, stories, notes), but it omits userId entirely and does not clarify the distinction between vocabularyDo and vocabularyAvoid or the meaning of the enums.
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 uses a specific verb ('Creates or updates') and resource ('the voice profile for a user'), and enumerates the relevant content areas. This clearly distinguishes it from read-only siblings like get_voice_profile and from broader tools like update_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?
The phrase 'creates or updates' implies that this tool is appropriate both for new voice profiles and for modifying existing ones. However, it gives no explicit guidance on when to prefer bootstrap_voice_profile, get_voice_profile, or update_profile instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It openly reveals that this mutates the runtime overlay and that effects appear without redeployment. Still, it does not say whether existing selectors are overwritten, whether the operation is idempotent, or what happens on failure.
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?
The description is one crisp sentence with a front-loaded action and a useful consequence. Every word earns its place; there is no filler or repetition of schema details.
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?
The tool itself is simple and the schema defines the parameter shapes, so the description is close to sufficient. However, without annotations or an output schema, an agent still lacks context about preconditions (what 'reviewed' requires), whether the change persists, and what the tool returns on success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain what selectorId and strategies mean beyond their schemas. It only says 'selector entry', which gives domain context but does not clarify the role of either parameter or how strategies relate to the selector.
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 verb and resource: 'applies a reviewed selector entry to the runtime overlay'. It is not a tautology and communicates a distinct action from siblings like approve, reject, or dry_run, though it does not explicitly name a sibling for comparison.
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?
The phrase 'applies a reviewed selector entry' implies this is the post-review application step, and 'fixes land without a redeploy' clarifies when it is useful. However, there are no explicit when-to-use or when-not-to-use guidelines, and no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Returns' makes the read-only nature clear and the field list gives some expectation about the response, but it does not disclose authentication needs, visibility restrictions, or behavior when the identifier does not match a profile.
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?
The description is a single sentence with no filler. It front-loads the core action and resource, and every phrase contributes useful information.
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?
The tool is simple, but because there is no output schema and no annotations, the description must carry more context. It lists the main fields but omits error behavior, identifier format, and any access constraints, leaving partial ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only restates the parameter name as 'identifier' without defining what form it takes (e.g., numeric ID, URL slug, public username). This does not meaningfully add beyond the input schema.
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 states a specific verb ('Returns'), a clear resource ('member profile'), and the lookup key ('by identifier'), and it lists the returned fields. This makes the tool's purpose immediately distinguishable from siblings like get_me by the identifier-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_me, get_connections_summary, or get_posts. The phrase 'by identifier' weakly implies a use case, but no explicit context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that the artifact is redacted and lists what it contains, which gives the agent some expectation about output sensitivity and composition. However, it does not explicitly state whether retrieval is side-effect-free, what happens for invalid or missing artifacts, or how redaction may limit the data.
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?
The description is a single, front-loaded sentence with no filler. Every phrase adds relevant information: the action, the redaction behavior, and the artifact's contents.
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 one-parameter retrieval tool, the description covers purpose and high-level return contents, but it omits the semantics of 'id' and any indication of when an artifact is available. Without an output schema, a bit more detail about the artifact's structure or failure conditions would have made this fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'id' parameter, but it never explains what 'id' refers to or how to obtain it. The name and title weakly imply it is a failure artifact identifier, but the description adds no explicit parameter meaning beyond the schema.
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 uses a specific verb ('Returns') and resource ('failure artifact'), and goes beyond the title by naming the artifact's contents: failed request, failed strategies, and optional DOM dump. This clearly distinguishes show_artifact from the general social and registry sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like audit_draft, dry_run, or plan. The description implies it is for retrieving failure artifacts, but it does not state when this is appropriate or when another diagnostic tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose that the operation is destructive ('Removes') and what the operation returns ('the verified skills state'), which is useful. However, it does not mention whether the skill must already exist, whether removal affects endorsements or other related data, or what error conditions may occur.
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?
The description is a single sentence with the action front-loaded and the result stated immediately. Every word earns its place, and there is no redundant or vague filler.
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 mutation tool with no annotations and no output schema, the description gives only a basic picture: removal by URN and return of the verified skills state. It does not cover side effects, preconditions, or failure behavior, so while it is not severely incomplete, an agent is left with notable gaps for a write operation.
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?
The schema only defines skillUrn as a required string with no description, making this 0% covered. The description partially compensates by clarifying that the parameter is a 'profile-skill URN', which conveys it is not a generic skill ID but a URN for a specific profile-skill association. Still, it provides no format, example, or additional constraints.
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 states a specific verb ('Removes') and a clear resource ('a skill by its profile-skill URN'), making the action unmistakable. It also distinguishes this tool from siblings like add_skill, endorse_skill, and reorder_skills, all of which concern skills but are not removal operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as remove_connection, delete_post, or the other skill-related tools. It only implies usage through the verb 'removes', leaving the agent to infer suitability and prerequisites on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does reveal that the operation edits fields and returns a verified profile read-back, which is useful, but it omits other behavioral details such as whether the update is partial or wholesale, and whether any permissions or side effects apply.
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?
A single sentence front-loads the action, names the editable fields, and states the return behavior. There is no filler or repetition of schema details.
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 simple optional-parameter mutation, the description covers the basics and the return value. However, it is ambiguous how topSkills interacts with the dedicated skill-management siblings, and in the absence of annotations or an output schema, a bit more context about partial-update semantics would be needed for fully confident invocation.
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 0%, so the description must compensate. It maps all three properties ('headline', 'about', 'topSkills') into readable semantics, but adds no deeper meaning about format, constraints, optionality, or whether an omitted field is left unchanged.
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 states a specific verb ('Edits'), the exact target resource ('headline, about, or top-skills'), and the resulting behavior ('returns the verified profile (read-back)'). This clearly differentiates update_profile from profile-viewing and post-editing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many skill-related siblings such as add_skill, remove_skill, and reorder_skills. An agent is left to infer whether topSkills replacement is the intended route or whether those sibling tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does add useful context by mentioning the quota-checked endpoint and that LinkedIn invite limits surface as clear errors. However, it does not disclose other side effects, authentication requirements, or what happens on success.
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?
The description is a single, front-loaded sentence with no filler or repetition. Every clause adds relevant information about the action, the endpoint behavior, and error handling.
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?
The tool is relatively simple with only two string parameters, and the description provides the core purpose plus an important behavioral caveat about invite limits. However, with no output schema, no annotations, and no parameter-level details, important context about return values and parameter formats is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only references the 'note' parameter implicitly ('with a note') and does not explain the profileUrn format, note length, or any constraints. This leaves the agent under-informed about how to fill both required parameters correctly.
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 clearly states the action ('Sends a connection request') and the resource, making it immediately distinguishable from sibling tools like respond_invitation or follow. The phrase 'with a note' also adds necessary specificity about the request's contents.
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?
The description implies when to use the tool—sending a new connection request—but it does not explicitly discuss alternatives or conditions for avoiding this tool. The context is sufficient to infer the primary use case, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It clearly states the tool performs an additive write action ('Leaves a reaction'), which is transparent about mutating behavior. However, it does not disclose whether a reaction replaces an existing one, whether repeated calls are idempotent, or what side effects occur.
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?
The description is a single, tightly composed sentence that front-loads the action and target, then lists the allowed values. Every word earns its place, and there is no redundant filler.
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?
The tool is simple, with only two required parameters and no output schema, so the description covers the essentials of what and where. However, it omits the return behavior, error conditions, and whether the reaction is additive or replacing, leaving moderately important operational context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. It only restates the reaction enum already present in the schema and gives minimal context for postId ('on a post'). It does not explain the meaning of each reaction, postId format, or behavior for invalid inputs, leaving the parameter semantics under-specified.
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 states a specific verb ('Leaves a reaction') and a specific resource ('a post'), and enumerates the exact reaction types. This distinguishes it from the sibling react_to_message by explicitly scoping to posts, so there is no ambiguity about the tool's core function.
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?
The description implies the tool is used when you want to react to a post, but it gives no explicit guidance on when to prefer it over alternatives like react_to_message or comment. It provides only implied usage context, not explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. 'Replaces a post's text' clearly signals a mutation that overwrites existing content, and 'verifies the edit by read-back' discloses a post-write verification step. It does not cover prerequisites or side effects, but for a simple two-parameter edit operation this is reasonably transparent.
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?
The description is a single, front-loaded sentence with no filler. The main operation ('Replaces a post's text') comes first, and the verification behavior adds meaningful detail without bloating the text.
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 simple mutation tool with only two required parameters and no annotations or output schema, the description covers the core operation and verification behavior. However, it does not describe the return value, error handling, or prerequisites, and it lacks explicit usage guidance relative to sibling post-related tools.
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 0%, so the description must compensate. It clarifies that the text parameter is the replacement content for the post, but it does not explicitly explain that postId identifies the target post or provide additional parameter-level context. The parameter meanings are mostly recoverable from names and the description, but not fully explicit.
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 uses a specific verb, 'Replaces,' with a clear resource, 'a post's text,' and adds the distinctive behavior of verifying by read-back. This differentiates it from siblings like create_post and delete_post by making the edit operation unambiguous.
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?
The description implies the tool is for modifying an existing post rather than creating or deleting one, but it does not explicitly state when to use it over alternatives. There is no direct contrast with create_post or delete_post, and no conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Nothing executes' is a valuable, non-obvious side-effect disclosure that clarifies this is a state change only. It stops short of mentioning reversibility or response behavior, but the core safety-relevant behavior is covered.
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?
The description is nine words with no filler. It front-loads the state transition and adds the critical 'nothing executes' qualifier in a compact, easy-to-parse sentence.
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?
The description is adequate for a one-parameter state-change tool, but with no annotations and no output schema, it leaves gaps around invalid states (e.g., non-pending plans) and any additional side effects. It gives the essential context but remains thin.
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 0%, so the description must compensate. The single planId parameter is self-explanatory by name, and the description adds the 'pending' precondition and 'rejected' outcome. However, it does not explicitly bind planId to the plan being rejected or describe error conditions for non-pending plans.
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 clearly states the action ('marks'), the resource ('plan'), the precondition ('pending'), and the resulting state ('rejected'). It also distinguishes itself from execution-oriented siblings by adding 'nothing executes'.
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?
The description implies when to use the tool: when a pending plan should be rejected rather than executed. However, it does not explicitly name alternatives such as approve or dry_run, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses what inputs are analyzed (posts, emoji, sentence length) and that the result is a starting profile, but it does not say whether the tool persists anything, requires special permissions, or returns a profile object. Moderate transparency for an unannotated tool.
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?
A single, front-loaded sentence with no wasted words. It states the action, the input source, the analysis dimensions, and the intended follow-up in one compact line.
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 simple two-parameter tool with no output schema, the description provides enough to understand what the tool does and roughly how to call it. It lacks explicit return-value or persistence details, but these are partly implied by 'derives' and 'tune it afterwards.'
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 coverage is 0%, so the description must compensate. It does add meaning by implying that samples are pieces of the user's past posts and that userId selects the user. However, it never explicitly maps each schema parameter or explains constraints like minimum sample count.
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 names an exact verb ('derives'), a specific resource ('starting voice profile'), and the method ('emoji use and sentence length'). It clearly distinguishes this bootstrapping step from sibling tools like get_voice_profile and set_voice_profile.
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?
'Tune it afterwards' clearly situates this tool as the initial step before further adjustment, which differentiates it from set_voice_profile. It gives context but does not explicitly name alternative tools or state exclusion cases such as 'do not use if a profile already exists.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure on its own. It clearly states the key side-effect-free behavior: nothing is stored and nothing can be approved. It does not cover authentication or error behavior, but for a dry-run the critical guarantees are present.
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?
Only one sentence; the key non-storage/approval caveat is front-loaded. No filler.
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?
Given no output schema and no annotations, the description should do more. It adequately explains behavior and outcome ('same plan and previews as plan'), but lacks any mention of how to structure `actions` or what the preview output contains. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The `actions` parameter is not mentioned in the description, and schema description coverage is 0%. The agent must rely on the raw schema (array of tool/args objects with an enum) without any guidance on how actions relate to 'plan', ordering, or validation semantics.
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 states a specific verb ('Produces') and resource ('same plan and previews as plan'), and immediately differentiates itself from the sibling 'plan' by noting nothing is stored or approvable. This leaves no ambiguity about the tool's core role.
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 provides clear context by contrasting with 'plan' and explicitly stating that nothing can be approved, which signals safe preview use. It lacks an explicit 'use when' formula or list of when-not to use, but the contrast is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only states that profile view counts are returned, without mentioning time period, privacy scope, rate limits, or whether this is a read-only operation. This is minimal disclosure.
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?
A single sentence that front-loads the verb and resource. Every word contributes meaning, and there is no redundancy or filler.
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 no-parameter, read-only lookup tool, the description is nearly complete. It states what is returned and for whom. The main gap is lack of detail about the nature of the counts (e.g., time period or data source), but given the tool's simplicity this is a minor omission.
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?
There are zero parameters and schema coverage is 100%, so there is no parameter meaning for the description to add. The instruction baseline for zero parameters is 4, and the description appropriately avoids inventing parameter details.
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 states a specific verb ('Returns'), a precise resource ('profile view counts'), and a scope ('for the signed-in member'). This clearly distinguishes it from siblings like get_profile or get_posts, which return different data.
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?
The phrase 'for the signed-in member' establishes clear context that this tool returns the caller's own analytics and needs no parameters. It does not name alternative tools or explicitly state when not to use it, but the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the key behavior of returning an error when no profile exists, and it implies a read-only operation. However, it does not mention authentication requirements, side effects, or any details about the returned voice profile structure.
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?
The description is a single, focused sentence that front-loads the main action and includes the key error case. Every word contributes value and there is no redundancy.
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 simple one-parameter read tool, the description is mostly adequate. However, since there is no output schema, it would benefit from specifying what a voice profile contains or at least referencing its structure. The error case is covered, but the return value remains vaguely defined.
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 schema provides no description for the userId parameter, but the description's phrase 'for a user' connects the parameter to its purpose. Since there is only one required parameter and its name is self-explanatory, the description adds enough meaning despite 0% schema coverage.
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 clearly states the action ('Returns the voice profile'), the target resource ('for a user'), and the error condition ('or an error if none exists yet'). This makes the tool's purpose obvious and distinguishable from siblings like set_voice_profile and bootstrap_voice_profile.
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?
The description clearly establishes that this tool is for retrieving an existing voice profile, which implies the read use case. It does not explicitly name alternatives or exclusion criteria, but the retrieval framing provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the operation only reports status, enumerates the possible session-health outcomes, and reveals whether the server is read-only. It does not explicitly state that the call has no side effects, but 'reports' strongly implies a non-mutating check.
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?
A single, tightly worded sentence that front-loads the core purpose ('Reports the health of the LinkedIn session') and includes all key return states without filler or repetition.
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?
For a zero-parameter status-check tool with no output schema, the description is complete: it defines all relevant output categories and the additional read-only signal. An agent knows what the tool returns and can interpret the result without needing further context.
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 zero parameters, and the baseline for zero-parameter tools is 4. There is nothing a parameter description could add, and the description correctly focuses on behavior rather than inputs.
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 uses a specific verb ('Reports') and an unambiguous resource ('health of the LinkedIn session'), and enumerates the exact result states: healthy, unhealthy with a reason, or no-session, plus the read-only server flag. This clearly differentiates it from sibling tools like get_me, login, or dry_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, when not to use it, or how it relates to login or dry_run. The intended use is only implied by the name and general purpose, not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a solid job: it discloses that this is a gated write operation equivalent to direct tool calls and that actions execute sequentially. It does not spell out post-conditions or failure behavior, but the core side-effect profile is visible.
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?
One dense sentence that front-loads the core behavior (executes pending plan) and adds relevant detail (ordering and gated write path) without any filler.
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 one-parameter execution tool with no output schema, the description covers purpose, target, and side-effect nature. It is slightly incomplete around planId provenance and what happens after execution, but overall an agent can confidently invoke it.
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 coverage is 0%, but planId is a single self-explanatory string and the description ties it to the pending plan. It adds no information about where the planId comes from or how to validate it, so it only partially compensates for the missing schema description.
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?
Description states a specific action ('executes the actions') on a specific resource ('a pending plan') and adds ordering ('in order'), which clearly separates it from sibling tools like dry_run, reject, and plan. The title 'Approve a plan' reinforces the focus.
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 clearly situates the tool as the approval/execution step for a pending plan, so an agent can infer when to call it versus dry_run or reject. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly states what the tool scans, what it returns (suggested fixes), and a behavioral boundary (never rewrites). It does not specify the exact shape of the suggestions or explicitly note read-only status, but 'never rewrites' sufficiently communicates non-destructive intent for a simple audit tool.
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?
One tightly written sentence packs in the tool's purpose, the full list of what it detects, the output type, and its key limitation. The parenthetical list is specific but not bloated, and the key 'never rewrites' distinction is placed at the end for emphasis.
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 one-parameter tool with no output schema, the description adequately explains the input, the detection criteria, and the kind of result to expect. The only minor gap is that the format of the suggested fixes is not described, though the main usage scenario is clear without it.
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 coverage is 0% and the only parameter, text, is minimally described. The description compensates by calling the input 'a draft,' but it stops short of clarifying input constraints, format expectations, or edge cases. For a single self-descriptive parameter, this is acceptable but not richly elaborated.
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 identifies a specific verb ('Scans') and resource ('a draft') and enumerates the exact AI tells it detects: inflated claims, formulaic structure, em-dash overuse, chatbot phrasing, robotic rhythm. It also draws a clear line from sibling editing tools by stating it 'never rewrites'.
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?
The description communicates when to use this tool: to audit a draft for AI tells and get suggested fixes. The phrase 'never rewrites' implies it should not be used when a rewrite is needed, and the sibling edit_post is the natural alternative, though it is not named explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Returns' clearly signals a read-only operation, and specifying a count leaves little room for unexpected side effects. It does not discuss edge cases such as pending invitations, but that is a minor gap for such a simple read.
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?
A single sentence with no filler. The verb and key qualifier ('first-degree') are front-loaded, and every word contributes meaning.
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 no-parameter, no-output-schema tool, this is nearly complete: an agent can call it and understand the result. It could explicitly state that the count is for the authenticated user, but that is reasonably implied by the lack of parameters.
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 has zero parameters, so there is nothing for the description to document beyond the schema. Baseline 4 applies; the description appropriately focuses on the meaning of the returned value instead.
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 uses a specific verb ('Returns'), a specific resource ('first-degree connection'), and the exact output ('count'), making the tool's purpose unambiguous. This clearly separates it from broader siblings like get_analytics or get_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?
No explicit when-to-use or alternative guidance is given, but the single-purpose wording implies it should be chosen when the agent needs the numeric first-degree connection count. This is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the exact return fields and the 'signed-in' constraint, which is useful for a simple read operation. However, it does not mention error conditions, authentication requirements, or whether the data is current.
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?
A single sentence that states the resource and the exact returned fields with no filler or redundancy. Every word contributes to the tool's meaning.
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-only tool, the description is nearly complete: it names the resource and enumerates all returned data. It could mention what happens when no session exists, but the 'signed-in' phrasing already implies that precondition.
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 input schema is empty and there are zero parameters, so there is no parameter semantics gap. The description adds no parameter-specific meaning, but none is needed.
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 uses a specific verb ('Returns') and a clear resource ('the signed-in member'), and explicitly lists the returned fields: id, name, headline, vanity name. This distinguishes it from sibling tools like get_profile or session_status by scoping it to the current authenticated member.
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?
The description clearly implies this is for retrieving the caller's own member data, giving the agent a clear context for when to select it. It does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does well by revealing that the tool returns an idempotency originToken and that retrying with it prevents double-sends. It implies the create/send side effect, though it doesn't discuss notification or delivery behavior.
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?
Two sentences, front-loaded with the core action and followed by the most important behavioral detail. No filler or redundant repetition of the schema.
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 simple 3-parameter send operation, this is nearly complete: the action, target, and idempotency contract are all present. It would benefit from noting where conversationUrn comes from, but that is available through sibling get_conversations.
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 0%, so the description must compensate. It explains originToken's purpose explicitly, and text/conversationUrn are inferable from the action, but the URN format or how to obtain it is not described.
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 uses a specific verb and resource: sending a message within a conversation, and the originToken detail makes the action more concrete. This distinguishes it from sibling tools like comment, react, and react_to_message, which target different interaction types.
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 clearly sets the context (a conversation) and gives actionable retry guidance by telling the agent to pass the returned originToken on retries. It does not explicitly name alternatives or when-not-to-use, but the conversation scoping is a clear enough context signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden and does so admirably. It discloses verification by read-back, refusal to double-post, and honest reporting of verification failure, which are meaningful behavioral traits beyond a simple 'create' operation.
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?
The description is a single, front-loaded sentence with no filler. Every clause adds useful behavioral information about publishing, verification, and duplicate prevention.
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 one-parameter publish tool, the description covers the main action, verification, idempotency, and error honesty. It does not provide a full return schema or auth requirements, but the description still gives enough for an agent to call the tool correctly.
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 0%, so the description must compensate. It implicitly defines the lone `text` parameter as the post content, but does not add details like maximum length, formatting, or special handling. The coverage is adequate for one parameter but not thorough.
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 states a specific action ('Publishes a text post') and resource, and also differentiates from siblings by mentioning read-back verification and double-post prevention. An agent can clearly distinguish create_post from edit_post, delete_post, and comment.
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?
The description clearly implies when to use the tool: when publishing a new text post. It does not explicitly discuss exclusions or compare with sibling tools, but the purpose statement is unambiguous enough for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly discloses the most important safety behavior: nothing executes until approve. It also describes previews and that raw args remain available. It does not mention auth or failure modes, but the key non-mutating guarantee is well covered.
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?
Two sentences with no filler. The core transformation and the critical non-execution guarantee are front-loaded, and preview details are compactly summarized.
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 tool with a nested actions schema and no output schema, the description covers the essential behavior and output characteristics. It could say more about the exact returned plan structure or payment/auth expectations, but the current description gives an agent enough to call it correctly in the approve workflow.
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 0%, so the description must compensate. It adds meaning to the `actions` parameter by framing them as 'intended writes' and explaining what per-action treatment they receive. It does not fully narrate the object shape, but the schema already provides structure and the tool enum, and the description supplies the functional semantics.
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 uses a specific verb ('Turns intended writes into an ordered plan') plus a clear resource and scope. It also names what the output includes (per-action previews) and the non-execution behavior, making the tool's role clearly distinguishable from siblings like approve and dry_run.
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?
The description provides clear usage context: it is for intended writes before approval, and 'Nothing executes until approve' implies a sequencing constraint. It does not explicitly name alternatives or when not to use it, but the workflow implication is strong enough for an agent to infer correct invocation timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it discloses key traits: it opens a browser window, requires the user to sign in and close the window, and persists/restores the session. It does not cover failure modes or what the tool returns, but the main side effects are transparent.
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?
Two short sentences deliver the action, the user's required step, and the persistence behavior with no filler. The key 'one-time' instruction and close-window step are front-loaded.
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?
For a zero-parameter interactive login, the description is complete enough: it tells what the user must do, what the tool does, and what happens to the session afterward. No return format is necessary for correct invocation.
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 has zero parameters and 100% schema description coverage, so there is nothing for the description to add to parameter semantics. Baseline 4 applies because no parameter guidance is needed.
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 specific action—'Opens a browser window for a one-time sign-in'—and the title names the resource (LinkedIn). The 'one-time' wording also helps distinguish this interactive login from session-status or other account tools.
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?
The description gives clear context: this is a one-time, interactive setup whose session persists across restarts, so an agent knows not to call it repeatedly. It does not explicitly list alternatives or say 'use session_status if already signed in,' so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linkedin-mcp MCP server](https://glama.ai/mcp/servers/DarkLvrd/linkedin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DarkLvrd/linkedin-mcp)

Score Badge

Copy to your README.md:

[![linkedin-mcp MCP server](https://glama.ai/mcp/servers/DarkLvrd/linkedin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DarkLvrd/linkedin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DarkLvrd/linkedin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server