Linked API MCP

Server Quality Checklist

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

Latest release: v2.3.5
Disambiguation4/5
Most tools have clearly distinct targets and actions, with the nv_ prefix effectively separating Sales Navigator from standard LinkedIn operations. However, a few pairs like get_api_usage vs. admin_get_limits_usage and get_inbox vs. get_conversation could still cause initial confusion despite clear descriptions.
Naming Consistency4/5
All tool names follow a snake_case verb_noun pattern, and the admin_ prefix is applied consistently. The main inconsistency is the mix of retrieval verbs (get, fetch, retrieve) which are used based on subtle semantic differences, slightly reducing predictability.
Tool Count1/5
With 59 tools, the server vastly exceeds the 25+ threshold and clearly qualifies as an extreme mismatch per the rubric. The count is overwhelming, especially with many Sales Navigator duplicates, making it impractical for agents to select from efficiently.
Completeness4/5
The tool set provides comprehensive coverage for connection lifecycle, messaging, search, content interaction, analytics, and admin functions. Missing delete/update operations for posts or comments are minor gaps, but core workflows are well supported and no critical dead ends exist.
Average 4.3/5 across 59 of 59 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
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?
With no annotations provided, the description is the sole source of behavioral disclosure. It states the tool 'gets' something, implying a read-only operation, but it does not explicitly confirm that no changes are made, nor does it mention any permission requirements or return value characteristics. This is insufficient for full transparency.
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, clear sentence that is front-loaded with the verb 'Get.' It contains no filler or redundant wording, making it optimally concise and well-structured.
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 the tool's simplicity (one parameter, no output schema), the description provides the core information needed to invoke it. However, the lack of any explanation about the return value or how this differs from closely related sibling tools (e.g., admin_get_limits_usage) leaves some context incomplete for an agent.
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 input schema already fully describes accountId as 'Account UUID,' achieving 100% schema coverage. The description's 'for an account' merely repeats the schema's meaning without adding new semantics. Since the schema carries the burden, the baseline score of 3 is appropriate.
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 tool's purpose: 'Get configured rate limits for an account.' The verb 'Get' and the resource 'configured rate limits' are specific, and the scope 'for an account' is clear. However, it does not explicitly differentiate from sibling tools like admin_get_limits_usage or admin_get_limits_defaults, which could cause confusion.
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 guidance on when to use this tool versus the many similar admin_* sibling tools. There is no mention of alternatives or exclusions, leaving the agent to infer the appropriate context solely from the tool name and generic description.
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 burden of behavioral disclosure. It implies a read-only operation via 'Retrieve' and adds a clear parameter bound ('Date range must not exceed 30 days'), which is useful. However, it does not describe the shape of the returned statistics, whether any aggregation or filtering is applied, or other behavioral traits.
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 two sentences, immediately states the action and resource, and introduces the key constraint. There is no filler or redundant content; every sentence 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 two-parameter retrieval tool with no output schema, the description covers the core purpose and a critical limitation. However, it omits what the 'usage statistics' actually contain (e.g., counts, breakdowns) and any additional context such as authentication or rate limits, leaving the agent partially in the dark about expected results.
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 100%, as both parameters (start and end) have explicit descriptions including format examples. The description's phrase 'Date range' reiterates what the schema already conveys, adding no new semantic information about the parameters themselves.
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 'Retrieve' and names a clear resource 'Linked API usage statistics'. It effectively communicates the tool's primary function, though it doesn't explicitly distinguish itself from sibling tools like admin_get_limits_usage, which might also return usage-related data.
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 guidance on when to use this tool versus alternatives such as admin_get_limits_usage or retrieve_performance. The only added instruction is a 30-day date-range limit, which is a constraint rather than context about appropriate use cases or exclusions.
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. 'Get' suggests a read operation, but it does not explicitly disclose that it is non-mutating, mention any authentication or admin requirements, or explain potential side effects. The behavior is largely inferable from the verb and admin_ prefix, but not explicitly disclosed.
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 wasted words. It immediately states the action and target, making it highly scannable for an agent.
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 should at least hint at what the response contains or under what conditions it succeeds/fails. The term 'usage' is vague (e.g., numeric counts? limits? timestamps?), and no error or prerequisite context is given. The description is adequate for a trivial read, but incomplete for practical use.
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 100% (accountId is described as 'Account UUID'), so the schema already documents the only parameter. The description does not add any parameter-specific meaning beyond what the schema states, matching the baseline of 3.
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 ('Get') with a clear resource ('usage against configured rate limits') and scope ('for an account'). It is easily distinguished from sibling tools like admin_get_limits, which likely return the limits themselves, and admin_set_limits/admin_reset_limits, which modify 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 description implies a monitoring use case (checking consumption against rate limits) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, so guidance is only implied.
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 full responsibility for disclosing behavioral traits. It only notes the 'pending' state, but gives no details about idempotency, side effects, permissions, or what happens if the session is already active or completed.
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 precise sentence fully conveys the tool's purpose with no wasted words. This is appropriately concise and front-loaded.
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 (one parameter, no output schema), so the description is minimally adequate. However, it lacks any mention of return values, error conditions, or preconditions, leaving some gaps for an agent invoking the tool.
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 input schema has 100% coverage, already describing sessionId as 'Connection session UUID'. The description adds no additional meaning or context beyond the schema, so the baseline score of 3 applies.
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 ('Cancel') and the specific resource ('a pending connection or reconnection session'). This distinguishes it from sibling tools like admin_create_reconnection_session and admin_get_connection_session.
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 'pending connection or reconnection session' implies when to use this tool, but it does not explicitly state when not to use it or mention alternative tools (e.g., admin_disconnect_account for active sessions). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but discloses no behavioral traits beyond the implicit read-only nature of 'Get'. It does not mention authentication requirements, pagination, or what 'pending connection sessions' entails, leaving the agent with incomplete expectations.
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, concise sentence that immediately states the action and target. Every word is necessary, and there is 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 zero-parameter tool with no output schema, the description provides a basic understanding of the result (accounts and pending sessions), but leaves ambiguity about the response structure and the nature of 'pending connection sessions.' More detail could improve completeness without bloating the text.
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 the input schema is empty. Per the baseline for 0-param tools, the description need not explain parameters, and no further semantic detail is required.
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 tool retrieves all connected LinkedIn accounts and pending connection sessions, using the specific verb 'Get' and naming the resources. It differentiates from sibling tools like admin_get_connection_session (singular session) and admin_get_limits_usage (limits).
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 alternatives. The description only states what it does without mentioning contexts, prerequisites, or excluding cases such as retrieving a specific session via admin_get_connection_session.
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 must fully disclose behavioral traits. While 'Get' indicates a read operation, it does not explain what the returned status includes, error behavior, or any prerequisites like admin rights. The term 'reconnection session' adds some context but lacks detail on side effects or response format.
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 concise sentence that fronts the action and resource, with no redundant or extraneous information. Every word contributes to clarity.
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 adequate but not complete. It lacks details about the expected response structure or possible status values, which would be helpful given there is no output schema. It also does not clarify whether the tool is limited to admin contexts, despite the admin_ prefix.
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 already provides a description for sessionId ('Connection session UUID'), and coverage is 100%. The description adds 'reconnection' to the context, implying the sessionId could be from either a connection or reconnection session, which slightly expands the parameter's scope beyond the 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?
The description specifies the action 'Get' and the resource 'connection or reconnection session status' with the method 'by session ID.' It clearly differentiates from sibling tools like admin_create_reconnection_session and admin_cancel_connection_session, which handle creation and cancellation.
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 when you have a session ID and need its status, but it does not explicitly state when this tool should be preferred over alternatives such as check_connection_status or admin_cancel_connection_session. No 'when not to use' or alternative guidance is 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?
The verb 'Get' implies a read-only operation, and the description enumerates the returned data (status, trial eligibility, cancellation schedule). However, with no annotations provided, the description carries the full burden and does not disclose potential authorization requirements or error behavior, though this is less critical for a simple getter.
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, concise sentence that front-loads the purpose and includes no filler or redundant details.
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?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential purpose and scope. It could benefit from specifying the structure of the cancellation schedule or trial eligibility, but it is otherwise sufficient for an agent to select and invoke the tool.
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 the description need not explain parameter semantics. Per guidelines, a tool with 0 parameters gets a baseline of 4, and the description adds no unnecessary information.
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 tool retrieves subscription status, trial eligibility, and cancellation schedule, using the specific verb 'Get'. However, it does not explicitly distinguish itself from sibling admin_* tools, though the resource is unique.
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 guidance on when to use this tool versus alternatives like admin_get_limits_usage. It only states what it does, not the appropriate context or exclusions.
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 burden of behavioral disclosure. It mentions the background workflow and workflowId, but it does not disclose potential side effects (e.g., overwriting data), permission requirements, or any rate limits. For a mutation tool, this is a significant gap.
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 efficient sentences, front-loaded with the core action, and no waste. It quickly conveys the purpose, behavior, and return value.
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 (one param) and the description covers the key action and return. However, it lacks guidance on prerequisites (e.g., admin permissions) or how the returned workflowId can be used. This omitted context is important for an admin tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'accountId' is well-described as 'UUID of the account to refresh'. The description adds little beyond the schema, so the baseline score of 3 is appropriate.
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 verb 'Refresh' and the resource 'stored profile information for a connected account', and distinguishes this admin tool by its 'background reparse workflow' nature. It is specific and unique among the listed 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when refreshing stored profile information, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. No reference to related workflow tools like get_workflow_result is provided.
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. It discloses the action (reset) and scope (all rate limits), but does not mention that this is destructive, irreversible, or requires special permissions. An agent cannot assess the safety or side effects beyond what 'reset' implies.
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?
Single sentence, front-loaded with the action, no filler. Every word contributes to the meaning.
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 basic function but omits behavioral details (e.g., irreversibility, permission requirements, effect on existing custom limits). Without annotations, this is a gap for an admin mutate 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 already provides 100% coverage with accountId described as 'Account UUID'. The description adds minimal extra meaning ('an account') but does not need to, given the schema's completeness.
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 ('Reset') and identifies the resource ('all rate limits for an account') with a clear target state ('system defaults'). It distinguishes itself from sibling tools like admin_set_limits and admin_get_limits by indicating a restore-to-default action.
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 purpose implies when to use it (when wanting to restore defaults), but there is no explicit guidance on when to use this vs admin_set_limits or admin_get_limits, nor any exclusions or prerequisites. Usage context is implied rather than stated.
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. It mentions the creation side effect and return values, but does not disclose permission requirements, any invalidation of previous sessions, or reversibility. For a mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the main action, then gives the key return values. No wasted words.
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?
The tool has a single parameter and no output schema; the description names both output fields (reconnectionSessionId and reconnectionLink) and the required condition. It is complete for a simple tool, though additional info on admin authorization would improve 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 100% for the single parameter, so the description is not required to add parameter details. The description's mention of the prerequisite account status aligns with the schema's 'UUID of the account to reconnect' but does not add extra 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 clearly states the action ('Create a reconnection session') and the target resource ('account with status reconnection_required'). It distinguishes from sibling tools like admin_get_connection_session by emphasizing creation and the prerequisite status.
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 provides an implicit usage condition ('for an account with status reconnection_required') but does not explicitly discuss alternatives or when not to use. Since it lacks references to sibling tools like admin_get_connection_session or admin_connect_account, it only implies usage context.
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 adds the useful note that deleted limits fall back to system defaults, but it does not mention other traits such as irreversibility, required permissions, or partial failure behavior. This is a moderate level of transparency.
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 two sentences, front-loaded with the primary action and immediately provides the key consequence. Every word earns its place with no redundancy or fluff.
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 delete tool with two parameters and no output schema, the description is mostly complete. It explains the operation and the outcome (fallback to defaults), but could also mention return values or error behavior. Given the low complexity, the existing coverage is adequate.
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 100%, so the schema already documents both parameters and their nested structures. The description adds no additional parameter-level meaning beyond the phrase 'specific rate limits,' which somewhat aligns with the limits array but does not enhance understanding of individual fields.
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 tool deletes specific rate limits for an account, using a specific verb and resource. It also differentiates from sibling tools like admin_set_limits and admin_reset_limits by specifying 'specific' limits and noting the fallback to system defaults.
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 removing customized limits, but it does not explicitly contrast with alternatives like admin_reset_limits or state when to use it versus admin_set_limits. No explicit when-not guidance is provided, leaving the usage context somewhat 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?
No annotations are provided, so the description carries the full burden. It only states a read operation without disclosing authentication requirements, response format, or potential side effects. As an admin tool, it likely requires special credentials, which is not mentioned, leaving transparency 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?
The description is a single, clear sentence of six words, perfectly front-loaded and free of any redundancy or unnecessary detail.
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 0-parameter getter, the description is mostly complete. However, without an output schema, it does not specify the structure of the returned defaults, and the distinction from admin_get_limits could be slightly clearer. Still, it conveys the essential purpose effectively.
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 has 0 parameters with 100% coverage, so the baseline is 4. The description adds no parameter details, but none are needed since the tool takes no 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 clearly states 'Get system default rate limits' with a specific verb and resource. It effectively distinguishes itself from siblings like admin_get_limits (current limits) and admin_get_limits_usage (usage) by focusing on 'defaults'.
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 for retrieving default rate limits, but does not explicitly state when to use it versus alternative limit-related tools. The distinction is implicit through the word 'defaults', making it a usable but not well-guided tool.
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 it returns a sessionId and connectionLink that must be opened in a browser, which is a behavioral requirement. However, with no annotations, it doesn't mention session expiration, security implications, or whether it's a one-time link.
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?
Single sentence, front-loaded with the action, all words earn their place.
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 tool with no output schema, the description covers the action, the output, and the required next step. It could add info about session lifecycle but is largely complete.
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 no parameters, so schema coverage is 100%. The description adds context about the session flow, which is sufficient given zero 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 verb ('Create') and resource ('connection session to connect a new LinkedIn account'), clearly distinguishing it from sibling tools like admin_create_reconnection_session by specifying 'new' account.
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?
It implies usage for connecting a new account, but does not explicitly state when to use it versus admin_create_reconnection_session or other admin session tools. No alternatives 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. It clearly states that the action is irreversible and that the account must be reconnected from scratch, which is critical and non-obvious. It does not mention permissions or side effects beyond this, but for a simple disconnect action, this is strong transparency.
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 exceptionally concise: two sentences total. The first sentence front-loads the action and resource, and the second delivers a crucial warning. Every word earns its place, with 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 simple tool with one parameter, no output schema, and no annotations, the description covers the essential aspects: the action and its irreversible nature. It does not detail response formats or prerequisites, but given the minimal complexity, this is reasonably complete.
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 input schema already provides a complete description of the sole parameter, accountId ('UUID of the account to disconnect'), giving 100% schema coverage. The tool description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.
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 the specific verb 'Disconnect' followed by the resource 'a LinkedIn account,' clearly stating the tool's function. It distinguishes itself from sibling tools like admin_connect_account by focusing on the removal/irreversible action, and the irreversibility note adds important context without ambiguity.
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 through its clear action and resource, but does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives. Since the purpose is obvious and there are no exclusions or alternative references, it falls under 'implied usage'.
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 explains what a seat is and lists seat types, which adds context, but it does not explicitly state read-only behavior, return format, or authentication requirements. The verb 'Get' implies a read operation, mitigating the gap.
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 two sentences, front-loaded with the core action, and every sentence adds value. The seat type clarification is concise and directly relevant.
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 0-parameter read operation, the description provides sufficient context on what seats are and their types. No output schema exists, so return format is not specified, but the tool's action and scope are clear enough for an agent to invoke correctly.
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 the schema is empty with 100% coverage, so the baseline is 4. The description adds meaning about seats and their types, though no parameter details are needed or provided.
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: 'Get active subscription seats' clearly states the action and object. It distinguishes this tool from siblings like admin_set_seats and admin_get_accounts by focusing on seats, and it adds valuable detail about seat types.
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 for reading subscription seats but does not explicitly state when to use it versus alternatives like admin_set_seats or admin_get_subscription_status. No exclusions or alternative guidance are provided; context is clear but not explicit.
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. It explicitly states a key behavioral consequence: 'The old token becomes invalid immediately.' This reveals the destructive/irreversible nature of the action. It does not mention other potential side effects or prerequisites, but the most critical behavior is disclosed.
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 two sentences, front-loaded with the action, then a concise behavioral consequence. No wasted words or redundant information.
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 tool with one parameter and no output schema, the description covers the essential aspects: what it does and the immediate consequence. It does not explain the response format or admin requirements, but these are not critical given the tool's simplicity and the admin_ prefix in the name.
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 input schema fully documents the single parameter accountId with description 'UUID of the account' (100% coverage). The description adds nothing beyond the schema, but per the rubric baseline is 3 when schema coverage is high.
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: 'Regenerate identification token for an account.' This clearly differentiates it from sibling tools like admin_connect_account or admin_disconnect_account, as it describes a distinct action on a distinct resource.
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 it (when an identification token needs regeneration) but provides no explicit comparison to alternatives or exclusions. Since the action is self-explanatory and no sibling tool performs the same function, the implied usage is adequate.
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 provided, the description carries the full burden and it excels: it explains the queued cloud-browser workflow, immediate pending response with status fields, long-poll mechanism, and distinct pending reasons like 'outsideWorkingHours'. It also warns against retrying to avoid duplicate queued work, which is valuable behavioral disclosure.
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 longer than typical but every sentence contributes necessary information about the async workflow and special cases. It is front-loaded with the core purpose, then explains the process in a structured, readable way. Slight redundancy (e.g., mentioning the operationName twice) keeps it from a 5.
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?
This is a complex asynchronous tool with no output schema, and the description covers all necessary context: immediate return shape, how to retrieve the final result via get_workflow_result, behavior for queued vs outsideWorkingHours, and instructions not to retry. It is complete enough for an agent to correctly invoke and follow up.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific detail beyond what the schema provides (e.g., mentioning 'when filter is not provided' for the since parameter), which is already in the schema. Thus the baseline of 3 is appropriate.
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 tool retrieves connections and names the underlying action (st.retrieveConnections). It is specific about the resource (connections) but does not explicitly contrast itself with sibling tools like retrieve_pending_requests or search_people, so it misses the differentiation that would merit a 5.
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 gives clear context on how to handle the asynchronous workflow (use get_workflow_result, don't retry while running), but it does not say when to choose this tool over alternatives like search_people for broader people search. The when-to-use is implied by the name and description, not explicitly stated.
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 discloses a key behavioral detail: if there is no active subscription, it returns a checkout link instead of updating, otherwise it updates immediately. This goes beyond a generic 'set' statement. However, it does not mention permissions, error conditions, or the exact response format for the successful update case, which keeps it from a 5.
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 two short sentences, front-loaded with the action and resource. It efficiently conveys both the core function and the important conditional outcome without unnecessary words. Every phrase adds value.
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 does not fully cover what happens after the update (response shape) or any prerequisites/errors. It explains the checkout-link branch but leaves the 'updates immediately' branch return value unspecified. Given the simple parameter set, the description is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters fully (quantity range, seatType enum with extra meaning, billingPeriod enum). The description adds no additional semantic detail beyond what the schema already provides, so it meets the baseline of 3 for high 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 a specific action ('Set number of subscription seats') and identifies the resource (subscription seats). It distinguishes from siblings like admin_get_seats (viewing) and admin_set_limits (different resource) by focusing on seat count. The conditional behavior also adds precision.
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 implies this tool is for changing subscription seat quantity, and it adds context by describing the two possible outcomes: returning a checkout link (no active subscription) or updating immediately. It does not explicitly exclude alternatives or name when-not-to-use, but the purpose is clear enough for an agent to select it over the many admin_* siblings.
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 full responsibility. It discloses long-polling behavior, timeout semantics, snapshot structure, and the special parked state for outsideWorkingHours, including that repeated calls return the same state. This covers key behavioral traits, though it omits potential rate limits or side effects (e.g., whether polling consumes credits).
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 appropriately sized given the tool's polling behavior and edge case. It is front-loaded with purpose, then return behavior, polling details, and exception. Sentences are information-dense but not padded, though the exception explanation could have been condensed slightly.
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 polling tool with no output schema, the description covers the essential usage flow, timeout handling, and special case. It does not describe the final success result's structure, but that is inherently workflow-dependent. Overall, it provides sufficient context for an agent to invoke and interpret responses 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 100%, with rich descriptions for all parameters. The description reinforces that workflowId and operationName come from the original call and explains waitSeconds semantics (defaults, 0 for snapshot), but these are already in the schema. The description adds minimal new value beyond the schema, so baseline 3 applies.
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 verb+resource: 'Check the current state of a previously started Linked API workflow.' It clearly distinguishes from siblings by focusing on result retrieval rather than starting (e.g., execute_custom_workflow) or other operations.
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?
Provides clear usage context: call after starting a workflow, poll with waitSeconds, and re-call with same workflowId and operationName if timeout. It also covers the outsideWorkingHours exception. However, it does not explicitly name alternatives or state when not to use the tool, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses async behavior, immediate return of pending status, the need to poll via get_workflow_result, and even distinguishes pendingReason values ('queued' vs 'outsideWorkingHours') with appropriate agent guidance. This is far beyond typical descriptions.
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 relatively long but every sentence addresses an essential aspect of the async behavior or status handling. It is front-loaded with the primary purpose and then expands systematically into workflow details. No wasted words, but a slightly shorter version might be possible.
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?
Though there is no output schema, the description fully explains the response shape, workflow lifecycle, and follow-up action (get_workflow_result). It also covers edge cases like outside working hours and budget elapse, making the tool's usage context complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds only a general mention of 'various filtering criteria' without enriching parameter semantics. The schema's own descriptions for term, limit, and filter fields are sufficiently detailed, so no additional value is provided.
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 'Allows you to search for companies applying various filtering criteria,' with a specific verb and resource. It does not explicitly differentiate from sibling tools like search_people or search_jobs, but the resource is unambiguous and the tool name reinforces the purpose.
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?
Provides detailed workflow guidance: explains that the tool returns immediately, instructs to call get_workflow_result with the returned IDs, and explicitly warns 'Do not retry the original tool while a workflow is still running.' It does not mention alternatives (e.g., search_people), but the workflow-specific usage is clear and actionable.
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 disclosure. It usefully states that only specified limits are changed and others remain unchanged, which is a key behavioral trait. However, it does not disclose other important behaviors such as validation of categories, required permissions, or error handling, leaving gaps for the agent.
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 two concise sentences. The first sentence clearly states the purpose and key behavior; the second lists valid categories. No words are wasted, and the most important information is front-loaded.
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?
Given the moderate complexity (nested object parameter) and the absence of an output schema, the description covers the essential context: what the tool does, the partial-update behavior, and accepted categories. It could additionally explain response behavior or validation, but the existing schema and description together are mostly sufficient 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?
Schema coverage is 100% for parameters, but the description adds the list of valid categories, which is not present in the schema. This provides meaningful additional semantic information beyond the schema's vague 'Limit category'. The partial-update behavior also clarifies how the 'limits' array is applied.
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 tool 'Set rate limits for an account', with a specific verb and resource. It further clarifies the scoped behavior ('Only specified limits are created or updated; other limits remain unchanged'), which distinguishes it from sibling tools like admin_reset_limits or admin_delete_limits.
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 context on what the tool does and its partial-update semantics, implying it is the appropriate tool for setting or modifying specific rate limits. However, it does not explicitly reference alternative tools or state when not to use it, so it falls short of explicit when/when-not guidance.
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, the description fully discloses the asynchronous behavior: immediate pending response, long-polling via get_workflow_result, duplicate-work risk on retries, and detailed explanation of pendingReason states including 'queued' and 'outsideWorkingHours'. This goes far beyond basic mutation/read hints and provides critical usage context.
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 three paragraphs, but each section earns its place: purpose, workflow mechanics, and edge-case handling. It is somewhat lengthy but not wasteful; the detail is necessary for correct asynchronous usage. The structure is logical and front-loaded with the core purpose.
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?
Given the complexity of the async workflow and nested parameters, the description thoroughly explains the immediate response, how to retrieve results, and how to handle pending states. However, it does not describe the final result structure (no output schema), though the name and purpose imply the content. Overall comprehensive for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only briefly mentions optional retrieval of employees, posts, and decision makers, but the input schema already provides detailed semantics for each parameter, including limits and filters. The description adds minimal new parameter-level 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 explicitly states that the tool opens a company page and retrieves basic information, with optional retrieval of employees, posts, and decision makers. It clearly identifies the resource (company) and action (fetch), distinguishing it from sibling tools like fetch_person or search_companies.
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 operational guidance on the asynchronous workflow, instructing the agent to call get_workflow_result with the returned workflowId and operationName, and explicitly warns against retrying the original tool while a workflow is running. However, it does not explicitly compare to alternative tools or state when not to use this tool, though this context is implicitly clear.
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 provided, the description fully carries the behavioral burden. It discloses that actions are queued into a cloud-browser workflow, the server returns immediately with a status object, retries can cause duplicate withdrawals, and how pending reasons like 'queued' and 'outsideWorkingHours' affect polling and user communication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into paragraphs but is somewhat overlong and contains redundancy. The warning about not retrying while a workflow is running appears twice (first and second paragraphs), and some workflow mechanics could be condensed without losing value.
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?
Given the tool's async workflow complexity and lack of an output schema, the description is remarkably complete. It explains the immediate response shape, how to obtain the final result via get_workflow_result, long-polling behavior, and how to handle different pending reasons, leaving no major gaps for an agent to act 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 100%, so the baseline is 3. The description does not add extra meaning to personUrl or unfollow beyond what the schema already provides; it focuses on workflow behavior rather than 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 uses a specific verb and resource: 'withdraw the connection request sent to a person' and names the underlying action (st.withdrawConnectionRequest). It clearly distinguishes this from siblings like send_connection_request, check_connection_status, and remove_connection.
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 operational context: when the workflow is running, do not retry; instead call get_workflow_result with the returned workflowId and operationName. It also explains how to handle 'queued' and 'outsideWorkingHours' pending reasons. It does not explicitly name alternative tools, but the usage context is strong.
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 provided, the description fully discloses the async behavior: immediate pending response, long-polling via get_workflow_result, request budget, duplicate-work warning, and the meaning of pendingReason values including outsideWorkingHours. This is exemplary transparency beyond what any schema could convey.
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 long but every sentence earns its place: purpose, async mechanics, retry warning, and pending-reason handling. It's front-loaded with the primary function and structured logically from immediate behavior to edge cases.
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?
The description explains the entire workflow lifecycle, return values, and how to handle pending states. However, it never explicitly states what the final result contains (e.g., the actual connection status values), relying on the tool name and purpose to imply that. For a complex async tool, this is a minor gap.
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 already covers personUrl with 100% description, including an example format. The tool description adds no additional parameter semantics, so it stays at the baseline of 3 for high 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 opens with a specific verb and resource: 'check the connection status between your account and another person.' It names the underlying API action (st.checkConnectionStatus), and the purpose is clearly distinct from siblings like send_connection_request or retrieve_connections.
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?
Provides concrete usage guidance: the action is asynchronous, must retrieve results via get_workflow_result, and warns not to retry while running to avoid duplicate queued work. It explains how to handle pendingReason values but does not explicitly contrast with alternative tools, though the purpose makes the appropriate context obvious.
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, the description fully discloses the queued execution, immediate pending response, duplicate risk on retry, pendingReason meanings, and long-polling behavior of get_workflow_result. This is rich, transparent behavioral disclosure beyond any structured metadata.
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 well-structured into paragraphs with a logical flow: purpose, retry warning, workflow mechanics, and pendingReason details. It is longer than typical but every sentence earns its place. Slightly dense but not wasteful.
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?
Covers the immediate response, async behavior, pending states (queued vs outsideWorkingHours), how to retrieve results, and retry precautions. Given the complexity and lack of output schema, this is complete and does not leave critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond 'optional media attachments' – all parameter constraints (max 9 images, etc.) are already in the schema. No additional semantic value provided.
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 'Creates a new LinkedIn post with optional media attachments' which is a specific verb and resource, clearly distinguishing it from siblings like comment_on_post or react_to_post. It also mentions the st.createPost action, adding specificity.
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?
Provides clear context about the asynchronous workflow, including queuing, pending status, and the need to call get_workflow_result for final results. It explicitly warns against retrying while running, but does not mention alternative tools or when not to use this tool, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: immediate return with a status object, long-polling behavior of get_workflow_result, duplication risks on retry, and the meaning of pendingReason values including 'outsideWorkingHours' with its non-polling behavior. This goes well beyond minimal 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 organized into three focused paragraphs, each addressing a distinct aspect: retry warning, workflow lifecycle with follow-up tool, and pendingReason handling. Every sentence provides essential information without fluff, and the most critical warning is front-loaded.
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?
The description thoroughly covers the asynchronous execution flow, retry hazards, and pending scenarios, which is impressive for a complex tool. However, the lack of any detail about the 'definition' object structure is a notable gap, preventing a perfect score.
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 only parameter 'definition' is an object with 0% schema coverage, and the description merely restates that it is a workflow definition without detailing its structure or expected fields. The description adds no meaningful parameter guidance, leaving the agent without necessary construction 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 ('Execute') and resource ('a custom workflow definition'), clearly identifying the tool's action. It also distinguishes itself from sibling tool get_workflow_result by explaining the asynchronous handoff, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when not to retry (while still running) and directs to call get_workflow_result with the returned workflowId and operationName. It also explains how to interpret pendingReason values and when to report to the user rather than loop, providing clear usage guidance and alternatives.
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 provided, the description carries full burden and exceeds expectations. It discloses the asynchronous cloud-browser workflow, immediate return with pending status, and the need to call get_workflow_result for final results. It also explains pendingReason values (queued, outsideWorkingHours) and advises against duplicate retries.
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?
Although the description is long, every sentence provides essential operational detail about the workflow, return values, and retry behavior. It is well-structured and front-loaded with the core action, but slightly verbose for a simple ignore action.
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?
Given no output schema, the description thoroughly covers the immediate response, workflow mechanics, how to retrieve final results, and how to interpret pending reasons. It is complete for the tool's complexity and integration with get_workflow_result.
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 input schema has 100% description coverage with detailed explanations for each parameter, including enums and conditional URLs. The description only reinforces that only the matching URL should be provided, which is already encoded in the oneOf schema, adding marginal value.
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 it ignores incoming connection, company-follow, or newsletter-subscription invitations, using a specific verb+resource structure. This distinguishes it from sibling tools like accept_invitation and retrieve_invitations.
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 explicit instructions on setting invitationType and providing only the matching URL, and warns against retrying while the workflow is running. However, it does not explicitly mention alternatives like accept_invitation for accepting, so it lacks direct when-to-use-versus-alternative guidance.
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, the description fully discloses the async queued workflow: it 'may take several minutes', returns immediately with a status object, and long-polls via get_workflow_result. It explains the pendingReason values 'queued' and 'outsideWorkingHours' and gives explicit instructions for each case, including not looping on outsideWorkingHours. This is exemplary transparency for a mutation 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 structured into three paragraphs, each carrying distinct information: core action, async response and retrieval pattern, and pending-state handling. It is longer than average but the complexity of the workflow justifies the length; every sentence adds operational value. It could be slightly tightened by merging repeated mentions of get_workflow_result, but it remains well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description compensates by explaining both the immediate return object and the eventual result retrieval via get_workflow_result. It covers the async execution model, retry avoidance, and edge cases like outsideWorkingHours. For a tool with this complexity, the description is comprehensive and leaves no critical operational gap.
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?
Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description reiterates the threadId source and operation, but adds no additional format constraints, examples, or edge-case semantics beyond what the schema already provides. Therefore it does not elevate above the baseline.
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 'Archive or unarchive a Sales Navigator conversation thread by threadId' — a clear action (archive/unarchive) applied to a specific resource (Sales Navigator conversation thread) with the key input identified. This distinguishes it from related tools like retrieve_feed or search, and the mention of 'nv.manageConversation action' ties it to a specific API operation.
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 explicitly states that the threadId should come from get_inbox and instructs the caller to retrieve the final result via get_workflow_result with the returned workflowId and operationName. It provides explicit guidance on when not to retry ('Do not retry the original tool while a workflow is still running') and how to handle queued vs outsideWorkingHours states. This gives robust operational context, though it does not contrast with the non-nv manage_conversation sibling.
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, the description fully discloses the asynchronous nature: actions are queued into a cloud-browser workflow, the server returns immediately with a pending/running status, and final results are retrieved via get_workflow_result. It also explains the queued vs outsideWorkingHours states, adding rich behavioral context.
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 well-structured and appropriately sized for the complexity. It front-loads the purpose, then details the workflow and pending reasons, with each sentence earning its place and no redundant fluff.
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?
The description thoroughly covers the async workflow and pending states, which is the primary complexity. However, it doesn't specify the structure or content of the final search result returned by get_workflow_result, which might be a gap since there is no output schema.
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 for parameters is 100%, so the baseline is 3. The description adds no additional parameter-specific semantics beyond referencing 'various filtering criteria' and the custom search URL override, which is already in 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 clearly states that the tool searches jobs with filtering criteria and names the underlying action (st.searchJobs), unambiguously distinguishing it from sibling tools like search_people and search_companies.
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?
Provides explicit workflow guidance: call get_workflow_result with the returned workflowId and operationName, and avoid retrying while the workflow is running. It also explains how to interpret pendingReason. However, it doesn't explicitly mention when to prefer this over alternative search tools, so it's not a 5.
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?
The description discloses the asynchronous workflow, immediate pending status response, the need to call get_workflow_result, duplicate comment risk on retry, and the meaning of pendingReason values including 'queued' and 'outsideWorkingHours'. This is substantial behavioral detail beyond annotations (which are absent).
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 longer than average but front-loads the purpose and critical retry warning, then efficiently explains the async workflow and pending reasons. Every sentence contributes necessary information without redundancy.
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?
With no output schema and no annotations, the description provides a thorough account of the tool's behavior, including the pending status object, workflowId/operationName usage, and edge cases like outsideWorkingHours. It adequately covers what the user/agent needs to know to use the tool and handle results.
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 input schema fully describes all three parameters (postUrl, text, companyUrl) with requiredness and length constraints, so schema coverage is 100%. The description adds no additional parameter details beyond what the schema already provides, meriting the baseline score of 3.
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 tool allows leaving a comment on a post, mentions the specific action (st.commentOnPost), and notes the return of the comment's URN and URL. This distinguishes it from siblings like reply_to_comment or react_to_post.
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 explicit guidance on when not to retry the tool (if workflow is still running) and how to retrieve results via get_workflow_result, including handling of outsideWorkingHours. However, it does not explicitly compare with alternative tools, though the tool name and purpose imply differentiation from reply_to_comment.
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 provided, the description fully shoulders the transparency burden. It clearly discloses the asynchronous queued nature, immediate server response with status, need for long-polling via get_workflow_result, and behavior for 'queued' vs 'outsideWorkingHours' pending reasons. This goes well beyond basic expectations and provides critical behavioral context.
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 well-structured: the first sentence states the core purpose, followed by concise paragraphs explaining the async workflow and pending states. Every sentence provides necessary information without redundancy or fluff, making it appropriately sized for the tool's complexity.
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?
Despite having no output schema and no annotations, the description is remarkably complete for a tool with this complexity. It explains the full workflow, the immediate response shape, how to retrieve final results, and edge cases like outsideWorkingHours. The only omission is the final result structure, but that is delegated to get_workflow_result, which is acceptable.
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 for the single parameter jobUrl is 100%, and the schema already includes a description and example URL. The description does not add extra parameter-level semantics beyond mentioning that it 'opens' the job, which is already implied. Baseline score of 3 is appropriate because the schema does the heavy lifting.
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 tool's function: 'Open a LinkedIn job and retrieve its details such as company, location, salary, and description' with a specific verb and resource. It also includes an explicit API action reference (st.openJob action) and distinguishes itself from sibling tools like search_jobs and fetch_company by focusing on individual job details.
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 substantial usage guidance for the async workflow: it explains to call get_workflow_result with the returned IDs, warns 'Do not retry the original tool while a workflow is still running', and provides specific handling for pendingReason values. However, it does not explicitly contrast with alternative tools like search_jobs for when to use fetch_job vs search, though the purpose implicitly covers this.
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 provided, the description carries the full burden and excels. It discloses the queued workflow, immediate pending status response, long-polling via get_workflow_result, anti-retry guidance, and detailed pendingReason semantics (queued vs outsideWorkingHours), including how those affect polling behavior. This is rich, non-obvious behavioral context.
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 long but each sentence contributes necessary information. It is structured logically: purpose first, then workflow behavior, then pending reasons. No fluff or redundancy; the detail is warranted given the tool's asynchronous complexity.
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 tool with no output schema and complex async behavior, the description is exceptionally complete. It explains the immediate return payload, how to retrieve results, what not to do (retry while running), and the meaning of pending states. It also covers why no final result is returned directly, leaving nothing about the tool's own behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema provides full parameter documentation. The description only adds a brief note that employees and decision makers can optionally be retrieved, which is a minor addition beyond the schema's already detailed descriptions. Thus, baseline 3 is appropriate.
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 tool opens a Sales Navigator company page to retrieve basic information, with optional employees and decision makers. The verb 'open' and resource 'company page' are specific, and the mention of the 'nv.openCompanyPage' action distinguishes it from sibling tools like fetch_company or search_companies.
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 explains the asynchronous workflow and instructs to use get_workflow_result for final results, which is key guidance. However, it does not explicitly contrast with alternatives like search_companies or fetch_company, nor state when not to use this tool, so it lacks explicit exclusions — though the context is clear.
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?
No annotations are provided, so the description carries the full burden. It thoroughly discloses the async behavior, immediate return status object, long-polling via get_workflow_result, and even explains pendingReason semantics ('queued' vs 'outsideWorkingHours'). This is exemplary transparency for a cloud-browser workflow 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?
The description is long but every sentence earns its place, covering critical workflow details, result retrieval, and edge cases. It is well-structured into logical paragraphs: action overview, async flow, and pending reason explanations. No unnecessary filler.
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?
Given the tool's complexity (async, cloud-browser workflow) and absence of both annotations and an output schema, the description is remarkably complete. It explains the immediate return, the long-polling process, and the two pending reasons with actionable guidance. The only minor omission is the specific fields of 'basic information,' but that is outside the description's scope.
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 100% and the parameter personHashedUrl is adequately described in the schema. The description does not add any additional meaning or usage detail about the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 tool's function: opening a person page in Sales Navigator to retrieve basic information, and identifies the underlying action (nv.openPersonPage). It distinguishes itself from sibling tools like nv_fetch_company by focusing on person pages, and from non-prefixed fetch_person by its async workflow.
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 strong context on how to use the tool: it explains the async workflow, instructs to call get_workflow_result for the final result, and explicitly warns not to retry while a workflow is running (a clear when-not). However, it does not compare this tool to alternatives (e.g., search_people or fetch_person) for finding people, so there is a minor gap in sibling differentiation.
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, the description carries the full burden of behavioral disclosure. It thoroughly explains that the action is queued, returns a status object immediately, and requires polling via get_workflow_result. It also discloses the two pending reasons and appropriate actions, making the async behavior fully 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 detailed but well-structured: it front-loads the purpose, then explains the async workflow, polling mechanism, and pending reasons. Every sentence contributes necessary operational context, with no filler or redundancy. The length is justified by the tool's complexity.
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?
Given the tool's async nature, lack of annotations, and absence of output schema, the description provides complete guidance: what the server returns, how to retrieve results, how to interpret pending reasons, and what actions to take or avoid. This is sufficient for an agent to invoke and follow up 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?
The input schema already provides complete descriptions for all parameters (100% coverage), including the filter sub-object. The description text does not add parameter-specific semantics beyond the schema; it only refers generically to 'various filtering criteria'. Therefore, the baseline 3 is appropriate.
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 tool's purpose: 'Allows you to search for companies in Sales Navigator applying various filtering criteria.' This is a specific verb+resource combination that distinguishes it from other tools. The mention of the underlying 'nv.searchCompanies action' adds precision.
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 explicit usage guidance: it explains the async workflow, instructs to call get_workflow_result, and warns not to retry while running to avoid duplicate work. It also details how to handle pending reasons like 'queued' and 'outsideWorkingHours'. However, it does not explicitly compare against the sibling 'search_companies' tool for synchronous alternatives, so it stops short of a full 5.
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 provided, the description fully discloses the queued cloud-browser workflow, immediate return with status fields, long-poll behavior, and the semantics of pendingReason values ('queued' vs 'outsideWorkingHours'). It also warns against duplicate queued work from retrying. This is exceptional transparency.
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 longer than typical but every sentence is necessary: purpose, async behavior, retry warning, and pendingReason explanations. It is structured logically, front-loading the core action and then detailing workflow implications, with no filler or redundancy.
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?
Given no output schema and no annotations, the description covers the return contract, workflow lifecycle, retry guidance, and edge cases like working hours. It is a complete usage guide for a complex async tool, leaving little ambiguity for the agent.
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 input schema has 100% description coverage for all parameters, including filter object semantics and enum ranges. The description adds no extra parameter-level detail beyond 'various filtering criteria,' so it meets the baseline 3 for high schema coverage without adding value.
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: 'search people in Sales Navigator applying various filtering criteria.' This clearly distinguishes it from sibling tools like nv_search_companies (search companies) and nv_fetch_person (fetch individual). The resource and verb are explicit.
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 detailed usage guidance for the async workflow, including when to call get_workflow_result and the warning not to retry while a workflow is running. However, it does not explicitly compare against alternative search tools like search_people or state when to choose this vs a non-nv variant, so it lacks exclusions.
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?
No annotations are provided, but the description thoroughly discloses the asynchronous workflow: queued actions, immediate server response with status fields, long-polling via get_workflow_result, and meanings of pendingReason values. This goes far beyond typical descriptions.
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 lengthy but every sentence contributes important behavioral context: async behavior, retry warnings, pending reasons, and result retrieval. It is well-structured with clear paragraphs and front-loads the purpose.
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?
Despite having no output schema, the description explains the returned status object, how to retrieve the final result via get_workflow_result, and how to handle different pendingReason scenarios. It fully covers the tool's complex async behavior.
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 input schema has 100% description coverage, so the schema already documents each parameter. The description adds no extra parameter-specific detail beyond what the schema provides, making the baseline 3 appropriate.
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 tool's purpose with a specific verb ('react') and resource ('post'), and mentions it supports all reaction types. It distinguishes itself from siblings like react_to_comment and comment_on_post by focusing on reacting to a post.
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 guidance on when to use the tool and critical usage constraints, such as not retrying while the workflow is running and using get_workflow_result to poll for results. It doesn't explicitly name alternative tools for different actions, but the workflow context is well explained.
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 provided, the description fully carries the burden of behavioral disclosure. It thoroughly explains the asynchronous workflow: immediate return with status, pending states (queued, outsideWorkingHours), the need to poll via get_workflow_result, and the consequence of retrying (duplicate queued work). This is exceptionally 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?
Though the description is longer than a simple one-liner, every sentence serves a critical purpose: defining the action, explaining the async behavior, and detailing the pending states. The structure is logical and front-loaded with the purpose, with no fluff.
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?
Given the tool's complexity (async workflow, no output schema, nested filter object), the description covers all essential context: what happens on invocation, how to retrieve results, how to interpret pending reasons, and how to handle outsideWorkingHours. It fully prepares the agent to use the tool correctly without needing additional information.
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 input schema provides descriptions for all parameters, achieving 100% coverage, so the baseline is 3. The description does not add significant parameter-level detail beyond the schema; it only mentions 'various filtering criteria' generically. It does not clarify usage of filter fields or any nuances beyond what schema already states.
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 tool's function: 'Allows you to search people applying various filtering criteria'. It names the underlying action (st.searchPeople) and the resource (people), distinguishing it from sibling search tools like search_companies and search_jobs by the target entity.
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 strong contextual usage guidance: it explains that the operation is async, instructs the user to call get_workflow_result with the returned workflowId and operationName, and warns against retrying the original tool while a workflow is running. However, it does not explicitly compare with alternatives such as nv_search_people or fetch_person, so it lacks explicit when-not-to-use guidance.
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, the description discloses the asynchronous workflow behavior, including immediate pending/running status, need to poll get_workflow_result, and prohibition on retrying while running. It also explains pendingReason variants (queued vs outsideWorkingHours), providing essential operational context.
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 structured with a clear purpose sentence, a performance warning, and a workflow explanation. While somewhat lengthy, each section earns its place and is logically organized, though it could be tightened slightly.
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?
Given the tool's complexity (async workflow) and lack of an output schema, the description thoroughly explains the initial response shape, how to retrieve the final result via get_workflow_result, and both pending reasons. It covers all necessary operational aspects 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 schema already covers all parameters at 100% coverage, so baseline is 3. The description adds value by warning that each additional retrieval flag increases execution time and recommending judicious flag usage, which informs how to set parameters beyond their type descriptions.
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 tool opens a person page, retrieves basic info, and optionally retrieves experience, education, skills, languages, posts, comments, and reactions. It also names the underlying action (st.openPersonPage) and distinguishes from siblings like fetch_company/fetch_post/fetch_job by focusing on person-specific retrieval.
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 for when to use the tool (when you have a person URL) and gives explicit guidance on when to set additional retrieval flags, warning that they significantly increase execution time. It also instructs to start with basic info and request more only if needed, though it doesn't explicitly name alternative tools or when-not-to-use.
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?
No annotations are provided, so the description carries full burden. It discloses the asynchronous queueing behavior, immediate server response with status, polling with get_workflow_result, duplicate-work risk on retry, and detailed pendingReason semantics (queued vs outsideWorkingHours). This goes far beyond a simple 'perform action' statement.
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 dense but not bloated; it front-loads the core action, then provides necessary workflow details in a structured manner. It could be tightened in places (e.g., 'may take several minutes' and later 'within minutes' could be condensed), but every sentence earns its place given the complex async behavior.
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 tool with no output schema, the description thoroughly explains the initial status response, how to get the final result via get_workflow_result, and edge cases including outsideWorkingHours. It provides enough to use the tool correctly end-to-end, including error/retry guidance. The complexity of the async workflow is fully covered.
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 100% with descriptions for both threadId and operation. The description adds minor context (e.g., threadId is 'as returned by get_inbox') but does not materially enrich schema semantics. Since schema already documents both parameters, a baseline 3 is appropriate.
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 clearly states the tool's purpose: 'Archive, star, or mute a conversation thread by threadId' and lists the specific operations. It distinguishes itself from siblings like get_conversation (read-only) and send_message (messaging) by specifying the management actions and the input source (threadId from get_inbox).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (when you have a threadId and want to archive/star/mute/unmute), and critically explains the asynchronous workflow: do not retry while a workflow is running, use get_workflow_result to retrieve the result, and handle pendingReason scenarios. This is clear, actionable guidance as good as alternatives.
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, the description fully discloses the asynchronous behavior: queued workflows, immediate server response shape, long-polling for results, and duplicate-removal risk on retry. It also explains the meaning of pendingReason values ('queued' vs 'outsideWorkingHours')—all essential beyond what annotations would provide.
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 verbose but appropriately structured into three logical sections: purpose, retry warning and workflow mechanics, then pendingReason handling. Every sentence carries actionable information, though it could be slightly tightened without losing clarity.
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?
Given the tool's complexity (async workflow, no annotations, no output schema), the description is remarkably complete. It covers the response format, how to poll for results, and edge cases like outsideWorkingHours, fully equipping an agent to handle 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 coverage is 100%: the personUrl parameter is fully documented in the input schema. The description adds no extra parameter semantics beyond referring to the person; the baseline 3 applies since the schema already does the heavy lifting.
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 tool's purpose: to remove a person from connections, and even names the underlying st.removeConnection action. This distinguishes it from sibling tools like send_connection_request or check_connection_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns against retrying while the workflow is running and directs the user to call get_workflow_result with the returned workflowId and operationName instead. It also provides guidance on how to handle the 'outsideWorkingHours' pendingReason, telling the agent to report to the user rather than loop.
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, the description carries full disclosure responsibility. It thoroughly explains the async cloud-browser workflow, immediate status response, the need for polling via get_workflow_result, duplicate-message risks on retry, and the meaning of 'queued' vs 'outsideWorkingHours' pending reasons. This is exemplary behavioral transparency.
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 lengthy but justified given the tool's async complexity. It is front-loaded with the core purpose and well-structured into sequential guidance. However, the retry warning appears twice (first paragraph and later), creating minor redundancy that prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: input alternatives, async workflow behavior, immediate response shape, result retrieval via get_workflow_result, retry prevention, and pendingReason interpretations. Given no annotations and no output schema, this is exceptionally complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all parameters including personUrl vs threadId and manageConversation semantics. The description adds some nuance ('threadId takes precedence', chained child action) but largely restates schema info, so a baseline 3 is appropriate.
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 'Allows you to send a message to a person (st.sendMessage action)', specifying the action and target. It also differentiates the two addressing modes (personUrl or threadId) and mentions the optional chained manageConversation, which is specific enough to distinguish from 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use personUrl vs threadId, notes that threadId takes precedence, and explains the optional manageConversation. It provides strong guidance on when not to retry (while workflow is running) and directs users to call get_workflow_result for the final outcome, including interpretation of pendingReason states.
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 provided, the description carries the full burden and handles it excellently. It discloses the queued cloud-browser workflow, immediate return shape with status/pendingReason/workflowId, the need to call get_workflow_result, and explains pendingReason variants including outsideWorkingHours. It also warns about duplicate queued work from retries.
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?
Despite being longer than average, each paragraph earns its place: purpose and retry warning, async workflow and result retrieval, and pendingReason semantics. The structure is logical, front-loaded, and free of filler, making it efficient for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with three conditional parameter shapes, no output schema, and background workflows. The description fully covers the return format, follow-up retrieval via get_workflow_result, retry dangers, and the outsideWorkingHours edge case. Nothing essential is missing for correct invocation and follow-up.
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 already provides 100% parameter descriptions with conditional requirements per invitationType. The description adds a helpful reinforcement by saying 'Set invitationType and provide only its matching URL,' clarifying mutual exclusivity. This goes slightly beyond the schema's oneOf structure without needing to duplicate 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 opens with 'Accepts an incoming connection, company-follow, or newsletter-subscription invitation,' using a specific verb and naming the resource. It also enumerates the three invitation types, clearly distinguishing it from siblings like ignore_invitation and send_connection_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context that this is for accepting incoming invitations and instructs to set invitationType and provide only the matching URL. It also provides critical usage warnings about not retrying while a workflow is running and redirecting to get_workflow_result. However, it does not explicitly state when not to use the tool or compare it to alternatives like retrieve_invitations.
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 provided, the description fully discloses the tool's asynchronous behavior: it queues into a cloud-browser workflow, returns immediately with a pending/running status, and may take minutes. It also explains pendingReason semantics ('queued' vs 'outsideWorkingHours') and the risk of duplicate work. This is rich behavioral context beyond what any annotation would provide.
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 front-loaded with the core purpose in the first sentence, then logically organized into workflow behavior and pendingReason details. Every sentence provides essential information, including actionable instructions for the agent. Length is justified by the complexity of the async workflow.
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?
Given the tool's complexity (async workflow, no output schema), the description is remarkably complete. It explains the immediate response, how to retrieve the final result via get_workflow_result, the meaning of pending reasons, and appropriate agent behavior. It covers all necessary operational context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'optional comments and reactions' but adds no meaning beyond the schema's detailed parameter descriptions. All parameter semantics are adequately handled by 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 clearly states a specific action: 'Open a LinkedIn post and retrieve its data, with optional comments and reactions.' It uses the verb 'retrieve' and identifies the resource (LinkedIn post). This distinguishes it from sibling tools like fetch_person or react_to_post, which target different resources or write actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use and when-not-to-use guidance. It instructs to call get_workflow_result for the final result, warns against retrying the original tool while a workflow is running (which creates duplicate queued work), and explains how to handle the 'outsideWorkingHours' pendingReason by reporting to the user rather than looping.
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, the description carries the full burden and does so thoroughly. It discloses the asynchronous workflow, immediate-ack behavior, pendingReason semantics, working hours parking, and the correct polling procedure. It even explains the ack format and the need to re-call after workflow completion, leaving no ambiguity about the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence serves a purpose: the first states the core function, the second explains the sync workflow, the third covers queuing and polling behavior, and the fourth handles edge cases for pending reasons. It is front-loaded with the main behavior and structured logically, making it easy to parse.
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?
Given the tool's complexity (async workflow), lack of output schema, and absence of annotations, the description covers all necessary context: immediate vs. deferred return, ack format, polling via get_workflow_result, retry prohibition, and pendingReason handling. No critical gaps remain for an agent to invoke the tool and handle the response 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 coverage is 100%, so the baseline is 3. The description does not add parameter-level detail, but the schema already fully documents both personUrl and since with examples and semantics. Therefore, no deduction or bonus is warranted.
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+resource: 'Retrieve a conversation with a LinkedIn person via standard LinkedIn messaging.' It clearly differentiates the tool's primary function from siblings like get_inbox or sync_inbox by focusing on a single conversation and explaining the sync workflow behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance: if the conversation is already synced, it returns immediately; if not, it starts a sync workflow and instructs the agent to call get_workflow_result. It explicitly warns 'Do not retry the original tool while a workflow is still running; that creates duplicate queued work.' Also details how to handle pendingReason values like 'queued' and 'outsideWorkingHours.'
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 provided, the description fully discloses the tool's asynchronous behavior: it queues a cloud-browser workflow, returns an immediate status snapshot, and requires long-polling via get_workflow_result. It also explains pendingReason values ('queued' vs 'outsideWorkingHours') and how get_workflow_result behaves in each case, covering what the agent needs to know beyond the schema.
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 front-loaded with the core purpose, then logically builds to prerequisites, async workflow, and pending handling. Every sentence carries essential information without fluff or repetition. It is longer than average but appropriately detailed for a complex async tool, and the structured progression aids comprehension.
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?
Given that this is an async tool with no output schema and no annotations, the description is remarkably complete: it specifies the immediate return payload fields, the follow-up call to get_workflow_result, the meaning of pending reasons, and even how to communicate waiting periods to the user. This covers all necessary context for correct invocation and result retrieval.
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 100% (type, since, threadId all have descriptions), so the baseline is 3. The tool description itself does not add significant parameter-level detail beyond what the schema already provides; it mainly reiterates that type filters standard vs Sales Navigator, which is already in the schema enum descriptions. Thus it meets the baseline but does not exceed it.
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 tool retrieves messages from the monitored inbox across all conversations (standard and Sales Navigator), newest first. This distinguishes it from siblings like get_conversation and retrieve_connections, and it includes a prerequisite (sync_inbox) that further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (after enabling inbox monitoring) and how to handle asynchronous results: use get_workflow_result with the returned workflowId/operationName, and do not retry the original tool while a workflow is running to avoid duplicate work. It also describes pending reasons and appropriate user reporting, providing clear usage guidance and alternatives.
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 provided, the description carries full burden. It thoroughly discloses the asynchronous behavior, return formats, workflow initiation, duplicate-work risk, and detailed handling of pending reasons (including outside working hours). This goes far beyond what structured annotations would typically provide.
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 well-structured with clear paragraphs for immediate behavior, workflow mechanics, and pendingReason semantics. Every sentence provides useful information without redundancy, despite the length being warranted by the complexity.
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?
Given the asynchronous nature and lack of an output schema, the description is exceptionally complete. It covers all relevant behaviors, return types, polling instructions, and edge cases like outside working hours. No important aspect is missing.
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 input schema already includes full descriptions for both parameters (personUrl and since), achieving 100% coverage. The description does not add additional parameter-level meaning, so the baseline score of 3 is appropriate.
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 ('Retrieve a conversation with a LinkedIn person via Sales Navigator messaging') that clearly distinguishes it from likely siblings like 'get_conversation'. It names the resource (Sales Navigator conversations) and the verb (retrieve).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: if the conversation is synced, return immediately; otherwise initiate a workflow and poll with get_workflow_result. It explicitly instructs not to retry the original tool while a workflow is running, and explains how to handle pendingReason values ('queued' vs 'outsideWorkingHours').
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?
No annotations are provided, so the description carries the full burden. It thoroughly discloses async queued behavior, immediate response shape, polling semantics, retry duplication risks, and working-hours parking 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?
Though multi-paragraph, every sentence delivers essential operational detail about async behavior, retries, and result retrieval. The structure is logical: purpose first, then workflow mechanics, then edge cases.
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 complex async tool with no output schema, the description fully covers return values, how to retrieve final results, retry pitfalls, and interpretation of pending reasons. It is complete for safe and correct 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 coverage is 100%: both commentUrl and type have descriptions and type is an enum with default. The description adds no new parametric meaning beyond what the schema already provides, so the baseline of 3 applies.
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 verb and resource: 'React to a comment by commentUrl', followed by the exact reaction types. This clearly distinguishes it from siblings like react_to_post and reply_to_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use/when-not-to-use guidance: do not retry while workflow is running, call get_workflow_result for final result, and explains pendingReason values like 'queued' and 'outsideWorkingHours' with appropriate agent actions.
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, the description fully discloses the asynchronous queued behavior: 'Linked API actions are queued into a cloud-browser workflow and may take several minutes.' It details the server's immediate status response, the retry duplicate risk, and the meaning of pendingReason values including 'outsideWorkingHours'. This is extensive and goes far beyond the bare 'reply' action.
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?
Although long, every sentence covers a necessary operational or safety aspect: purpose, return values, queuing, retry warning, result retrieval, and pending reason explanations. The structure front-loads the purpose and then logically progresses through workflow behavior, with no 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?
Given the tool's async complexity, the description covers not only the action but also the immediate response format, how to obtain the final result, how to interpret pending states, and how to handle the outsideWorkingHours case. The input schema handles parameters, and the description fully explains the behavior and output semantics, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'text' (with character limit) and 'commentUrl' (LinkedIn URL) are already described in the schema. The description adds no additional parameter semantics beyond 'by commentUrl' — it does not explain formats, defaults, or constraints beyond what the schema provides. Thus the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Reply to a comment by commentUrl' and explicitly states the outcome: 'returns the reply's URN and URL.' This unambiguously distinguishes it from sibling tools like comment_on_post (commenting on a post) and react_to_comment (reacting) by focusing on replying to an existing comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not guidance: 'If this workflow is still running, do not retry this tool; retrying can post duplicate replies.' It also directs the user to an alternative: 'call get_workflow_result with the returned workflowId and operationName' to retrieve the final result. This gives clear exclusion and alternative usage.
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?
No annotations are provided, so the description fully carries the burden. It discloses the async queueing, immediate return status, pendingReason values ('queued' vs 'outsideWorkingHours'), long-polling behavior of get_workflow_result, and the risk of duplicate work from retrying. This goes far beyond a simple read 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?
Three paragraphs each serve a distinct purpose: core action, workflow mechanics, and edge-case handling. Every sentence adds value, and the length is justified by the tool's asynchronous complexity.
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?
Despite no output schema and no annotations, the description fully explains the initial return object, status values, pendingReason semantics, and how to obtain the final result via get_workflow_result. It also covers working hours edge cases and duplicates prevention, making it complete for an async tool.
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 already fully describes the only parameter `limit` with min, max, and default. The description adds no additional parameter-specific context beyond this. With 100% schema coverage, the baseline score is 3.
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 ('Retrieves') and resource ('posts from the current account's personalized LinkedIn home feed'), making the tool's function unambiguous. It distinguishes itself from siblings like retrieve_connections and get_inbox by specifying 'home feed'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call get_workflow_result with the returned workflowId and operationName for the final result, and warns against retrying the original tool while a workflow is running. Also gives clear guidance on handling pendingReason 'outsideWorkingHours' by reporting to the user rather than looping.
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 provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the asynchronous nature, immediate return status, polling via get_workflow_result, the meaning of pendingReason values (queued vs outsideWorkingHours), and the risk of duplicate work from retrying.
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 longer than average, but the asynchronous workflow is complex enough to justify the detail. The first sentence front-loads the purpose, and subsequent sentences explain the workflow without excessive padding. A slightly shorter version could still be effective, but the current length is acceptable.
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?
It thoroughly covers the async workflow, the immediate response, polling, pending reasons, and working-hours handling. The only gap is the lack of description of the final result payload (since there is no output schema), but the essential usage context is complete for an agent to invoke the tool and follow up correctly.
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 the schema is trivially complete at 100% coverage. The baseline of 4 applies, and no parameter-specific explanation is needed since there are no parameters to describe.
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 first sentence specifies exactly what is retrieved (connection, company-follow, and newsletter-subscription invitations) and names the action (st.retrieveInvitations). This clearly distinguishes it from sibling tools like retrieve_connections or accept_invitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step usage: call retrieve_invitations, then use get_workflow_result with the returned workflowId and operationName. It also explicitly warns against retrying while a workflow is running and explains how to handle outsideWorkingHours, effectively covering when to use the tool and when not to.
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 provided, the description fully discloses the async behavior, immediate return status, polling mechanism via get_workflow_result, duplicate risk from retries, and handling of 'queued' vs 'outsideWorkingHours'. This is comprehensive for an async 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?
The description is dense but well-structured, covering the action, workflow, retry warning, and pendingReason handling in a logical order. Every sentence adds value for an async LinkedIn API action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the immediate return object, how to track the workflow, and how to handle the two pending states. It doesn't need to describe the final result shape since that belongs to get_workflow_result, making this complete for the tool's scope.
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?
All three parameters have detailed descriptions in the input schema, and the tool description adds nothing beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
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 tool sends a connection request to a person via the st.sendConnectionRequest action. The verb and resource are specific, and it is distinct from sibling tools like withdraw_connection_request or send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: it warns against retrying while a workflow is running to avoid duplicate queued work, and directs the user to call get_workflow_result for the final result. It also explains how to interpret pendingReason values, providing both when-to-use and when-not-to-use guidance.
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 provided, the description takes full responsibility for behavioral disclosure. It thoroughly explains the asynchronous nature: the server returns immediately with a status object, the action is queued into a cloud-browser workflow, and get_workflow_result must be polled. It also details pendingReason meanings ('queued' vs 'outsideWorkingHours') and instructs on the correct action for each, including not looping when outside working hours. This exceeds what annotations would typically provide.
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 well-structured and front-loaded with the core purpose, then dives into the async workflow and edge cases. It is thorough but not verbose — every sentence adds actionable information (e.g., status fields, pendingReason handling, the prohibition on retries). The three-paragraph format is easy to scan and each paragraph covers a distinct aspect: purpose, async workflow, and pending-state semantics.
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?
Given the complexity of the async workflow and the lack of an output schema, the description is remarkably complete. It explains the immediate return value, how to retrieve the final result via get_workflow_result, the long-poll behavior, and both pendingReason cases with explicit instructions for the agent. It even covers the 'request budget' aspect, making the description sufficient for an agent to handle the entire lifecycle without further documentation.
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 has zero parameters, so there is no parameter-specific semantics to add. The description focuses on the tool's operation and return values instead. Per the rubric, a baseline of 4 is appropriate for 0 parameters; the description adds meaning by explaining the output and workflow behavior, which is the next best thing.
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 tool's purpose: 'Enable whole-inbox monitoring so every incoming conversation can be polled with get_inbox'. It uses a specific verb ('Enable') and resource ('whole-inbox monitoring'), and distinguishes it from the related get_inbox tool by explaining the enablement prerequisite. It also clarifies the scope ('Run once per account') and a key behavioral constraint ('only messages that arrive after it is enabled are captured').
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 must be run once per account before get_inbox can poll, and it explicitly warns against retrying the tool while a workflow is running ('Do not retry the original tool while a workflow is still running') to avoid duplicate work. It does not directly compare to sibling alternatives, but the one-time setup instruction and workflow handling guidance effectively tell the agent when to use it and how to proceed after invocation.
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, the description fully discloses async queuing, retry risks (duplicate messages), the immediate return with pending status, long-poll behavior, and details of pendingReason values including outsideWorkingHours. This is exemplary transparency.
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 longer than average but every section earns its place given the complex async behavior. The first sentence front-loads the core action, and subsequent paragraphs cover queuing, retrieval, and edge cases. Minor redundancy in retry warnings, but acceptable for emphasis.
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?
Despite no output schema, the description explains the immediate response structure, how to retrieve final results, and how to interpret pending reasons. It covers the full lifecycle of the operation, making it complete for a complex async tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds valuable relational semantics: threadId takes precedence over personUrl, and subject is ignored when replying via threadId. This goes beyond individual parameter descriptions and clarifies usage interactions.
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 ('send a message to a person in Sales Navigator') and identifies the specific operation (nv.sendMessage). It distinguishes from siblings by noting the cloud-browser workflow nature and by requiring either personUrl or threadId, which is a unique input mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not guidance ('do not retry this tool' while workflow is running) and directs users to call get_workflow_result for final results. Also explains when pendingReason indicates waiting vs. after-hours parking, giving clear context on how to react.
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 provided, the description fully discloses the async behavior: the server returns immediately with a pending/running status, the final result must be fetched via a separate tool, and retry behavior is explained. It also details the pendingReason semantics and what to report to the user, giving deep behavioral context beyond the basic action.
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 fairly long but every sentence contributes necessary information about the async workflow and edge cases. It is front-loaded with the core purpose, then systematically explains the return payload, companion call, and pendingReason behaviors, so the length is justified and well-structured.
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?
Given the tool's complexity (async workflow, no output schema, no annotations), the description covers everything needed: the immediate return payload, how to retrieve the final result, duplicate-work warning, and handling of both pendingReason cases. It is complete for an agent to use the tool correctly.
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 schema coverage is effectively 100% and the description adds no parameter detail. The baseline of 4 is appropriate because no parameter explanation is needed; the description instead focuses on the workflow and return value 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 clearly states the tool retrieves performance analytics from the LinkedIn dashboard, using a specific verb+resource construction. It is distinct from sibling retrieve_* tools like retrieve_connections or retrieve_ssi by naming the specific analytics domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells the agent to call get_workflow_result with the returned workflowId and operationName, warns against retrying the original tool while the workflow is running to avoid duplicate work, and explains how to handle different pendingReason values including queueing and outside working hours.
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 provided, the description fully discloses the async behavior: immediate return with status, long-polling via get_workflow_result, duplicate work risk on retry, and handling of outsideWorkingHours. This is rich behavioral context well beyond what structured fields would convey.
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 long but every sentence serves a purpose: purpose, prerequisite, event types, async workflow, retry warning, and pending states. It is front-loaded with the core purpose and all extra detail is essential for correct usage.
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?
Given the async workflow complexity and no output schema, the description covers the entire lifecycle: initial return, result retrieval, retry prevention, pending states, and working hours behavior. It leaves no critical manual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear. The description adds value by explaining the semantic meaning of each event type enum value and clarifing the 'since' parameter's ISO 8601 format, going slightly beyond the schema's descriptions.
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 'Get connection events from the monitored network, newest first,' which is a specific verb+resource statement. It further defines event types and the prerequisite of sync_network, clearly distinguishing this from sibling tools like retrieve_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite of enabling network monitoring with sync_network and provides detailed guidance on handling the async workflow: call get_workflow_result with the returned IDs, do not retry while running, and how to interpret pendingReason. This is explicit when-to-use and when-not-to-use guidance.
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, the description fully discloses the asynchronous behavior: immediate return with a status object, queuing into a cloud-browser workflow that may take minutes, and the correct follow-up method. It details the semantics of pendingReason ('queued' vs 'outsideWorkingHours') and the corresponding get_workflow_result behavior, covering edge cases.
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?
Though lengthy, the description is organized into three focused paragraphs: purpose and run-once semantics, async workflow and retry warning, and pendingReason interpretation. Each sentence adds essential operational detail without redundancy.
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?
Despite lacking an output schema, the description explains the immediate return object (status, pendingReason, workflowId, operationName) and the follow-up via get_workflow_result, including edge cases like outsideWorkingHours. It is complete for a tool that initiates an async workflow, as the final result is intentionally delegated to get_workflow_result.
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 has zero parameters, so there is nothing to describe. The description does not need to add parameter info; the 0-parameter baseline of 4 applies, and no ambiguity exists.
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 verb and resource: 'Enable whole-inbox monitoring in Sales Navigator' and explains its purpose in relation to get_inbox. It also clarifies the one-time setup and temporal scope ('only messages that arrive after it is enabled are captured'), distinguishing it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Run once per account' and gives a key rule: 'Do not retry the original tool while a workflow is still running; that creates duplicate queued work.' It instructs to call get_workflow_result with the returned workflowId and operationName, and explains how to handle pendingReason values, including not looping on outsideWorkingHours.
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?
No annotations are provided, so the description fully discloses the async queuing behavior, the immediate response format, and the need to poll via get_workflow_result. It also details the two pendingReason states and their implications, including duplicate work risk if retried.
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 detailed but well-structured, starting with a clear purpose statement, then explaining the async workflow and special statuses. Every sentence adds necessary context for correct use, making it appropriately sized and 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?
Given the tool's async nature with no annotations or output schema, the description covers the full lifecycle: initial response, follow-up polling, retry prevention, and handling of different pending reason states. It is sufficiently complete for an agent to invoke and follow up correctly.
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, so the schema already fully covers this (100%). The description adds context about return values but no parameter explanation is needed, meeting the baseline for 0-parameter tools.
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 tool retrieves pending connection requests sent from the account, with the specific API action st.retrievePendingRequests. It distinguishes from siblings like retrieve_invitations by specifying 'sent from your account'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on the asynchronous workflow: do not retry while running, call get_workflow_result with workflowId and operationName to get the final result. Also explains how to handle pendingReason 'queued' vs 'outsideWorkingHours', including when to report to the user instead of looping.
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 provided, the description fully discloses behavior: asynchronous queuing, immediate server response with status and workflowId, long-polling behavior, pendingReason semantics for 'queued' and 'outsideWorkingHours', and guidance against duplicate queueing. This is extremely 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?
While the description is longer than average, every sentence provides necessary operational detail. It is front-loaded with the primary purpose, then progressively covers workflow mechanics, retry guidance, and pendingReason interpretations. No filler or redundancy.
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?
Given the tool has no parameters and no output schema, the description compensates by fully explaining the return value structure, the need to call get_workflow_result, and the meaning of pendingReason variants. It is complete enough for an agent to use correctly without additional 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 has zero parameters, so there is no parameter detail to add. The baseline for 0 params is 4, and the description appropriately focuses on response handling rather than parameter 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 opens with a clear verb-object statement: 'retrieve your current SSI (Social Selling Index)', including the internal action name (st.retrieveSSI). This is specific and distinguishes it from sibling tools like retrieve_performance which target 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: call get_workflow_result with the returned workflowId and operationName, do not retry while a workflow is running, and how to handle pendingReason values. It clearly explains the asynchronous workflow and correct next steps.
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, the description fully discloses the async workflow behavior: immediate return with status and workflowId, potential multi-minute delays, and detailed pendingReason handling including 'outsideWorkingHours' parking. This goes far beyond a simple 'enable' and explains exactly what the agent should expect.
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 well-structured in three paragraphs: purpose/setup, async workflow mechanics, and pendingReason edge cases. Each sentence adds necessary operational detail, and the front-loaded opening gives immediate clarity. Length is justified by the complexity of the behavior.
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?
Given the absence of annotations, output schema, and parameters, the description covers all critical aspects: what the tool does, how to invoke it, what the immediate response looks like, how to retrieve final results, how to avoid duplicate work, and how to handle special pending states. No obvious gaps remain.
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 the baseline is 4. The description adds context by noting the tool is a one-time setup, though it doesn't need to explain parameter meanings since none exist.
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: 'Enable background network monitoring so connection events can be polled with get_network'. It uses a specific verb-resource pair and references the related poll tool, distinguishing it from siblings like sync_inbox or get_network itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: 'Run once per account', 'only changes that happen after it is enabled are captured', and important exclusions like 'Do not retry the original tool while a workflow is still running; that creates duplicate queued work.' It also directs to get_workflow_result for completion, offering clear guidance on next steps.
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:

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

Score Badge

Copy to your README.md:

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

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/zecloud/remote-mcp-linkedin'

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