Sliq

Set Linkedin Daily Limits

set_linkedin_daily_limits

limits is a partial {action: cap} map — only the actions you name change, the rest keep their current cap. Each cap is clamped to that action's tier-aware ceiling (the ceiling in check_linkedin_daily_usage's configurable_limits); a cap of 0 or below resets that action to its default. Action keys are the configurable_limits keys (connection_request, message, inmail, …); an unknown key is rejected with the full valid list.

The number the user sets is the day-to-day center, not a fixed count: like Sliq's defaults, each cap carries a small ±jitter so sending doesn't read as automation, so the actual daily number varies by a few around the set value (never above the tier ceiling). Tell the user the value you set, not that they'll send exactly that many.

Owner-only — these are account-level account-safety settings. Returns {success, custom_daily_limits}, the resulting stored cap map. Dict with success and the stored custom_daily_limits map.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limits`	Yes	Partial map of action -> daily cap. 0 or below resets that action to default.
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

First observedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive write. The description goes well beyond that: caps are clamped to a tier-aware ceiling, 0-or-below resets to default, unknown keys are rejected with the full valid list, the set value is a jittered center rather than a fixed count, and it is owner-only account-level configuration. It even states the exact return shape ({success, custom_daily_limits}), which nothing else provides.

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?

Front-loaded with the summary and the trigger condition, and the jitter paragraph, though long, earns its place because it changes what the agent should tell the user. Some tightening is possible — the ceiling reference and the jitter caveat repeat the tier-ceiling idea — but there is no padding.

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?

No output schema exists, and the description compensates by naming the return shape and pointing at check_linkedin_daily_usage for post-write verification. With mutation semantics, reset/clamp behavior, the jitter caveat, permission scope, and error behavior all covered, an agent has everything needed to call this correctly and to report the result honestly.

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 the baseline is 3, but the description adds real meaning the schema lacks: partial-merge semantics ('only the actions you name change'), clamping behavior, the 0-resets rule, the action-key vocabulary, and the unknown-key rejection path. The only gap is that on_behalf_of is never mentioned in the description, so agency-context behavior is left entirely to 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?

States a specific verb and resource ('Change the user's per-action LinkedIn daily caps') and ties it to the exact settings surface it maps to (the AI Preferences settings card). It is trivially distinguishable from siblings like check_linkedin_daily_usage (read) and set_linkedin_warmup (a different account setting).

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?

Explicit trigger ('when the user asks to raise or lower how many connection requests, messages, InMails...'), an explicit anti-pattern ('actually make the change, don't just describe the UI'), and a follow-up instruction pointing at the sibling check_linkedin_daily_usage for verification. It also states the owner-only precondition, which routes the agent away from using on_behalf_of carelessly.

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

All Sliq tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?