Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lenx MCP Server list my monitoring tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server bridging AI agents to the Lenx.ai social media monitoring API.
Run directly via npx (no local installation required):
npx @fastaai/lenx-mcpOr install globally:
npm install -g @fastaai/lenx-mcp
lenx-mcpRelated MCP server: mcp-metricool
The server requires two environment variables:
Variable | Required | Description |
| Yes | Your Lenx API key |
| Yes | Your Lenx user ID |
| No | API base URL (default: |
Add to your Claude Code MCP configuration:
{
"mcpServers": {
"lenx": {
"command": "npx",
"args": ["-y", "@fastaai/lenx-mcp"],
"env": {
"LENX_API_KEY": "your-api-key",
"LENX_USER_ID": "your-user-id",
"LENX_BASE_URL": "https://open.lenx.ai"
}
}
}
}Add to your ~/.config/opencode/opencode.json:
{
"mcpServers": {
"lenx": {
"command": "npx",
"args": ["-y", "@fastaai/lenx-mcp"],
"env": {
"LENX_API_KEY": "your-api-key",
"LENX_USER_ID": "your-user-id"
}
}
}
}Tool | Description |
| List monitoring tasks with pagination |
| Get task details by ID |
| Create a live or adhoc task via a guided confirmation wizard (requires elicitation) |
| Update a task's name, search query, or prompts via a guided confirmation wizard (requires elicitation) |
| Delete a task after explicit confirmation (requires elicitation) |
| Get paginated post data for a task |
| Request CSV/XLSX export via email |
| Trigger an async data fetch for a task |
Note:
lenx_create_task,lenx_update_task, andlenx_delete_taskare interactive wizards that collect their input through MCP elicitation forms and require explicit confirmation before applying changes. The client must support elicitation; these tools will not work otherwise.
# Install dependencies
npm install
# Run tests
npm test
# Build
npm run build
# Watch mode
npm run watchMIT
Create a new monitoring task (live or adhoc). Live tasks run continuously; adhoc tasks require a date_range.
| Name | Required | Description | Default |
|---|---|---|---|
| task_type | Yes | Task type: 'live' runs continuously, 'adhoc' requires date_range | |
| task_name | Yes | Task name (1-50 characters) | |
| language | Yes | Language: zh-t (Traditional Chinese), zh-s (Simplified Chinese), en (English) | |
| date_range | No | Required for adhoc tasks: time range for data collection | |
| search_query | Yes | Search query configuration. Example query_layer with nested grouped keywords: [{"in": ["brand_name", "product_name"], "ex": ["competitor_name"]}] Nested OR-group form: [{"in": [["brand_name", "brand_alias"], ["product_series_a", "product_series_b"]], "ex": [["competitor_a", "competitor_b"]]}] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose key behavioral traits. It states the tool creates a task but does not mention side effects, authentication needs, rate limits, or what happens upon creation (e.g., returns task ID). The description is basic and leaves important behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core purpose and key distinction. No extraneous information; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is fully documented, but there is no output schema. The description does not mention what the tool returns (e.g., task ID, status). For a create operation, this is a gap. However, given the input schema completeness, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantics of task_type (live vs adhoc) and that date_range is required for adhoc. This goes beyond the schema's enum descriptions and clarifies conditional requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new monitoring task' and distinguishes between live and adhoc types. It uses a specific verb and resource, and the purpose is unambiguous. It differentiates from siblings (e.g., delete, update) which perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use live vs adhoc tasks: 'Live tasks run continuously; adhoc tasks require a date_range.' While it does not explicitly mention when not to use or alternatives, the guidance is sufficient for a typical agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a monitoring task. Only the task owner can perform this operation.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It states the destructive nature (delete) and the ownership requirement. However, it does not detail what happens on success or failure (e.g., whether deletion is permanent or reversible), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two clauses in one sentence. Every word adds value, stating the action, the resource, and a key constraint. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with a single required parameter, the description adequately covers the core functionality and an important precondition. It does not explain error handling or return values, but these are often implicit for delete tools. Given the lack of output schema, the completeness is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the parameter description 'Task ID to delete' is clear. The tool description adds the context that the task is a 'monitoring task', but does not provide additional semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a monitoring task'), making the purpose unambiguous. It also specifies the ownership constraint, which adds to clarity. This distinguishes it from siblings like lenx_create_task or lenx_update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: only the task owner can perform the operation. This helps the agent understand when the tool is applicable. However, it does not explicitly mention when not to use it or suggest alternatives, though for a delete operation, this is rarely needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a CSV or XLSX export of task post data. Results are sent to the specified email address.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | Array of task IDs to export (strings are auto-converted to numbers) | |
| unix_start | Yes | Start of export time range (unix timestamp) | |
| unix_end | Yes | End of export time range (unix timestamp) | |
| columns | Yes | Columns to include in the export file | |
| file_format | Yes | Export file format: csv or xlsx | |
| Yes | Email address to send the export to | ||
| is_comment | No | Include comments in export | |
| dedupe | No | Deduplicate posts in export | |
| limit | No | Maximum number of posts to export | |
| recipients | No | Additional email recipients | |
| email_subject | No | Custom email subject line | |
| timezone | No | Timezone for date formatting in export |
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 that results are sent to an email address, indicating asynchronous behavior beyond typical synchronous returns. This adds key behavioral context, though it omits potential side effects like rate limits or delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly stating the core function and delivery method. No extraneous information, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 12 parameters and no output schema, the description adequately explains the primary action and result. It covers the export format and delivery mechanism, though it does not mention constraints like file size limits or processing time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description mentions 'CSV or XLSX' and 'specified email address', aligning with file_format and email parameters, but adds no further semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports task post data as CSV or XLSX and sends it via email. The verb 'request' is appropriate, and it distinguishes itself from sibling tools like lenx_get_task_data by specifying the export-and-email delivery method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting and emailing but lacks explicit guidance on when to use this tool versus alternatives like lenx_get_task_data. No exclusions or conditions are provided, so the agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve configuration and metadata for a single monitoring task by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID |
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 indicates a read operation ('retrieve'), but lacks details on side effects, error behavior, or permissions. For a simple retrieval it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words with no filler. Every word is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one parameter, no output schema), the description covers what the tool does and what identifier is needed. However, it is vague about what 'configuration and metadata' includes and lacks error handling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter with description 'Task ID'). The tool description adds no additional parameter context, so value beyond schema is minimal. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Retrieve' and resource 'configuration and metadata for a single monitoring task by ID'. It distinguishes from siblings like 'lenx_list_tasks' (multiple tasks) and 'lenx_get_task_data' (data, not config/metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a specific task by ID, but provides no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve paginated social media post data for a specific task within a time range.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID | |
| from | Yes | Start unix timestamp (inclusive) | |
| to | Yes | End unix timestamp (inclusive) | |
| size | Yes | Number of posts per page (max: 1000) | |
| search_after | No | Cursor for pagination: pass the last post's unix_timestamp to get the next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. While 'retrieve' implies a read-only operation, it does not explicitly state side effects, auth requirements, or rate limits. No pagination behavior beyond the one-word mention is explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (12 words) that front-loads the key purpose: retrieving paginated social media post data for a specific task within a time range. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but is missing details like response structure (no output schema), pagination mechanics (though schema explains search_after), and when to use. It is adequate for a simple retrieval tool but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains all parameters (task_id, from, to, size, search_after). The description adds no additional parameter semantics, so it scores the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'social media post data' with specific constraints: pagination, specific task, and time range. It effectively distinguishes from sibling tools like lenx_get_task (likely task metadata) and lenx_list_tasks (list tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., lenx_get_task, lenx_export_task_data). The description does not mention prerequisites, limitations, or alternatives, which is a significant gap given the multiple sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List monitoring tasks accessible to the authenticated user, with pagination support.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| size | No | Items per page (default: 10, max: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions authentication context ('accessible to the authenticated user') and pagination, but lacks details on ordering, filtering, or rate limits. With no annotations, more behavioral disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information (verb and resource), no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not specify what fields or format the list returns. Users may need to infer from context; could benefit from stating return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full descriptions for both parameters (page, size). Description only mentions 'pagination support' without adding new semantic details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'monitoring tasks', distinguishing from sibling tools like lenx_get_task (single task) or lenx_create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like lenx_get_task for a single task, nor any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task's name and/or search query configuration. At least one field is required.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID to update | |
| task_name | No | New task name (1-50 characters) | |
| search_query | No | Partial search query update. Provide only the fields to change. Example: {"query_layer": [{"in": ["new_keyword"], "ex": []}]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only says 'Update', which implies modification, but fails to disclose key behaviors like partial update semantics (unspecified fields remain unchanged) or potential side effects. No mention of permissions, idempotency, or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and a parenthetical. It is front-loaded and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover more. It lacks information about the return value or response format after update. However, the input schema is detailed and sibling tools provide surrounding context. The description is adequate but not complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so the main description adds limited value beyond reinforcing 'at least one field is required'. The description does provide a useful constraint that is not in the schema, but overall it does not significantly enhance parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update', the resource 'existing task', and the specific fields that can be updated ('name and/or search query configuration'). It distinguishes well from sibling tools like lenx_create_task or lenx_delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage context by stating 'At least one field is required', but it does not explicitly mention when not to use this tool or compare it to alternatives. There is no guidance on prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.0.1lenx_create_tasklenx_delete_tasklenx_export_task_datalenx_get_tasklenx_get_task_datalenx_list_taskslenx_update_taskEach tool targets a distinct operation (create, delete, get, list, update, get data, export data) with no overlap. Descriptions clearly differentiate between task metadata and task post data.
All tool names follow the consistent pattern 'lenx_verb_noun' (e.g., lenx_create_task, lenx_list_tasks) using snake_case and clear verbs.
With 7 tools, the server covers essential CRUD operations, data retrieval, and export for monitoring tasks. The count feels well-scoped for a task management tool.
The tool surface provides full CRUD, listing, data retrieval, and export. Minor gaps like toggling task active state or getting export status are absent but do not severely impact core workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Social media analytics, post insights, and competitor benchmarking for AI agents.
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Social listening for AI agents: search mentions, pull scored buying signals, score leads
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ThinkCol/lenx-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
