lightbulb-mcp

Overview Schema Source Related Servers Discussions Admin

slack_lookup_user

Read-onlyIdempotent

Find a Slack user by looking them up through your project's connected Slack account. Returns the requested user's profile details.

Instructions

Slack connector operation lookup_user (platform tool slack.lookup_user).

Routes only through the exact project/account governed connector authority.

Args: arguments: JSON string of arguments for the connector operation. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema

Name	Required	Default
`effect`	Yes
`arguments`	No	{}
`project_id`	No
`project_ref`	No
`approval_ref`	No
`idempotency_key`	No
`connector_account_ref`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.1Sep 7, 2026

addedInput schema / properties / approval_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}

addedInput schema / properties / connector_account_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}

addedInput schema / properties / effect

Added value: +{
+  "const": "read",
+  "title": "Effect",
+  "type": "string"
+}

addedInput schema / properties / idempotency_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}

addedInput schema / properties / project_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}

addedInput schema / properties / project_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}

addedInput schema / required
```
Added value: +[
+  "effect"
+]
```

First observedv0.1.0Jun 25, 2026

TDQS

B3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: the operation is forced through a project/account governed authority, the effect must explicitly be read and is verified by Spring, and approval_ref is clarified as pertaining to write-resume scenarios.

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 concise and well-structured: it opens with the operation identity, states the routing constraint, and then provides a compact arg list. Each line contributes information, though the arguments line is slightly boilerplate and could be replaced with concrete payload guidance.

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?

An output schema exists and annotations cover the read-only safety profile, so return-value details are less necessary. But the core invocation detail is missing: what should actually go inside the arguments JSON for a Slack lookup_user operation. Without that, an agent cannot confidently construct the call, and the description also lacks usage context versus sibling Slack tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate; it does list all seven parameters with one-line explanations. However, the most important parameter, arguments, is only described as 'JSON string of arguments for the connector operation', which is circular and leaves the actual Slack lookup_user payload unspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the tool as the Slack connector operation lookup_user and maps it to the platform tool slack.lookup_user, but it never states in plain functional terms what a Slack user lookup does, such as retrieving a user's profile by ID or email. It also does not distinguish itself from Slack siblings like slack_users_info or slack_list_users, so the agent knows the resource area but not the exact operation semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is provided. The description mentions routing through a governed connector authority, but it does not explain when an agent should choose lookup_user over alternative Slack tools, nor what scenario this operation is designed for.

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

Deploy Server