@trylighthouse/mcp-server 0.2.12 → 0.2.15

package/build/server.js

@@ -85,7 +85,7 @@ export function createServer(apiKey, options = {}) {
     const api = new LighthouseAPI(apiKey);
     const server = new McpServer({
         name: "lighthouse",
-        version: "0.2.13",
+        version: "0.2.15",
     });
     const originalRegister = server.registerTool.bind(server);
     server.registerTool = (name, schemaOrConfig, handler) => {
@@ -548,7 +548,7 @@ export function createServer(apiKey, options = {}) {
         title: "List Record Activity",
         description: "Read the activity feed of one CRM record, newest first: who changed what, when, and from where. Use it to answer questions about history (\"what changed on this deal last week\", \"who moved it to won\", \"which fields has nobody touched\") instead of guessing from the record's current values. " +
             "Each entry has: action (created / updated / deleted / merged), occurred_at, summary (a ready-made sentence, ending \"via <the source>\" when a workflow or an API key made the change rather than a person, since both log a human as the actor), target ({ record_type, id, name }; the feed also carries the notes and tasks attached to the record, so the target is not always the record itself), actor (null for automated changes), and source. " +
-            "source always has { type, label }: type is app / mobile / api / mcp / workflow / ai_assistant / notetaker / email_sync / calendar_sync / linkedin_sync / inbound_email / inbound_whatsapp / lp_portal / sync, and label names the exact origin. The four trace keys are always present and null when the origin did not record them: workflow is { id, name, run_id, node_id } when a workflow made the change (tracing an entry back to the exact run and step), api_key_id / mcp_tool identify the key or AI tool behind an API change, and trigger is automatic or manual where the origin recorded whether a person asked for the change (meeting notes written on their own and notes a member asked for both log that member as the actor, so trigger is what tells them apart). " +
+            "source always has { type, label }: type is app / mobile / api / mcp / workflow / ai_assistant / notetaker / email_sync / calendar_sync / linkedin_sync / inbound_email / inbound_whatsapp / scout / lp_portal / sync, and label names the exact origin. The four trace keys are always present and null when the origin did not record them: workflow is { id, name, run_id, node_id } when a workflow made the change (tracing an entry back to the exact run and step), api_key_id / mcp_tool identify the key or AI tool behind an API change, and trigger is automatic or manual where the origin recorded whether a person asked for the change (meeting notes written on their own and notes a member asked for both log that member as the actor, so trigger is what tells them apart). " +
             "changes[] holds the field edits: { field, label, data_type, is_custom, list, previous, current }, where previous and current are each { value, display }: value is what is stored (an option value, a uuid, a number) and display is the same thing resolved for humans (an option's label, a linked record or user object). Consecutive edits to the same field by the same person on the same day are collapsed into one entry, so previous is the value before the burst and current the value after it. " +
             "Every entry has id, activity_id, action, occurred_at, summary, actor, source, target and changes. One save that changed several fields is reported as one entry per field: id stays unique per entry, activity_id is shared by the entries from that same save.  The five detail keys are on every entry and null on the entries they do not describe: note and task carry that note's / task's body inline (no follow-up call needed), merge carries { merged_record, kept_record }, document carries { type, id, name } for an attached file or folder, and related_records (an empty array when there are none) lists the OTHER records when one activity spanned several (never the entry's own target, which is already under target, and never the record whose feed this is). " +
             ACTIVITY_RELATED_RECORDS_LEFT_OUT + " " +
@@ -1691,13 +1691,13 @@ export function createServer(apiKey, options = {}) {
     });
     server.registerTool("lighthouse_documents_update_file", {
         title: "Update File",
-        description: "Rename, move, or change sharing on a file. Editors can rename/move-between-folders and delete; only the owner can move to root, change sharing, or grant team access. " +
+        description: "Rename, move, or change sharing on a file. Editors can rename and delete it. Only the owner can move it (into another folder or to the root), change sharing, or grant team access, with one exception: the owner of the folder the file is in can also move it into another folder they own. " +
             "team_ids replaces the current set when supplied. " +
             "Returns the file row: owner, is_owner, my_role, sharing, shared_with_teams[] (each { team_id, team_name, role, granted_at }), linked_records_count, size_bytes, content_type, created_at, updated_at.",
         inputSchema: {
             file_id: z.string().uuid().describe("File UUID, the file being changed"),
             name: z.string().optional().describe("New name"),
-            folder_id: z.string().uuid().optional().describe("New parent folder UUID, the folder the file is moved INTO (on lighthouse_documents_update_folder the same name means the folder being changed)"),
+            folder_id: z.string().uuid().optional().describe("New parent folder UUID, the folder the file is moved INTO (on lighthouse_documents_update_folder the same name means the folder being changed). The file's owner moves it into any folder they can edit; the owner of the folder it is in can also move it, but only into a folder they own; anyone else gets 403 forbidden. Naming the folder the file is already in also counts as a move, so to rename a file send only name."),
             clear_folder: z.boolean().optional().describe("Move to workspace root (owner-only)"),
             sharing: z.enum(["private", "workspace"]).optional().describe("Explicit override (null clears to inherit). The same word every other sharing tool takes, and the one a file answers."),
             sharing_status: z.enum(["PRIVATE", "WORKSPACE"]).optional().describe("Legacy name for sharing. Kept forever; sharing wins when both are sent."),
@@ -2602,7 +2602,7 @@ export function createServer(apiKey, options = {}) {
         "FUNNEL: {report_type:'funnel', entity_type:'company'|'deal'|'person' (custom objects are NOT supported for funnel), data_source:'companies'|'deals'|'people' (plural form of entity_type; ALWAYS include it or the widget opens with the wrong data source in the in-app editor; sending record_type instead fills both), stage_field:'<status field_key>', stage_field_is_custom:boolean (true when stage_field is a custom status field), " +
         "included_stages?:['stage1','stage2'], date_range?:{...}, filter?:{...} (same format and field support as the standard filter above, including relation fields like list_entries and custom fields; it restricts which records the funnel counts)}. " +
         "HISTORICAL: {report_type:'stage_changes', entity_type:'company'|'deal'|'person' (custom objects are NOT supported for historical), data_source:'companies'|'deals'|'people' (plural form of entity_type; ALWAYS include it; sending record_type instead fills both), " +
-        "field_permalink:'<status field_key>', time_grouping?:'day'|'week'|'month'|'quarter'|'year', included_stages?:['stage1','stage2'], date_range?:{...}}. " +
+        "field_permalink:'<status or select field_key>' (one value at a time, standard or custom, such as a deal's stage; a multi-select field, or a field Lighthouse computes such as relationship_status, is refused), time_grouping?:'day'|'week'|'month'|'quarter'|'year', included_stages?:['stage1','stage2'], date_range?:{...}}. " +
         "included_stages values must be the option VALUES from lighthouse_crm_list_attributes (not display labels). " +
         "ALWAYS call lighthouse_crm_list_attributes first to discover valid field keys for dimension, measure, and stage_field.";
     server.registerTool("lighthouse_reports_list_dashboards", {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trylighthouse/mcp-server",
-  "version": "0.2.12",
+  "version": "0.2.15",
   "description": "MCP server for the Lighthouse CRM API",
   "homepage": "https://trylighthouse.vc",
   "type": "module",