@awesomate/hosting-mcp 0.20.2 → 0.20.3

package/dist/index.js

@@ -40190,9 +40190,10 @@ async function knowledgeSources(config3, args) {
     if (args.action === "summary") {
       try {
         const s = await hubGet(config3, "/api/knowledge/sources/summary");
+        const failedJobs = Number(s.failed_jobs_7d ?? 0);
         return {
           ...s,
-          note: "Exact whole-library counts. by_kind is what the knowledge base answers from; the paged list is only for browsing individual sources."
+          note: failedJobs > 0 ? `Exact whole-library counts \u2014 BUT ${failedJobs} ingest job(s) FAILED in the last 7 days (last: ${String(s.last_failed_job_at ?? "unknown")}). Those uploads are NOT in the library even though every count here looks clean. Read awesomate_knowledge_sources {action:'jobs', status:'failed'} and tell the user which ingests failed before summarising the library.` : "Exact whole-library counts. by_kind is what the knowledge base answers from; the paged list is only for browsing individual sources."
         };
       } catch (err) {
         if (err instanceof HubApiError && err.status === 404) {
@@ -41535,7 +41536,7 @@ server.registerTool(
 server.registerTool(
   "awesomate_knowledge_sources",
   {
-    description: "The knowledge base's content sources. action 'list' \u2014 ONE page of sources, most recently ingested first (default 50, max 200 via limit): read `page.has_more`/`next_cursor` and pass cursor to continue \u2014 a page is never the whole library. 'summary' \u2014 exact whole-library counts {total, by_kind, chunks, indexed_chunks, failed_sources}: use THIS to say what the knowledge base contains. 'jobs' \u2014 ingest job statuses (optional status filter: queued|running|succeeded|failed). 'add' \u2014 ingest a public page {url} or a whole site {sitemap, since?}; ALWAYS get explicit approval first (ingest costs money and counts against quota), for a local FILE on the user's machine use awesomate_knowledge_upload instead (it streams the file from disk; this tool takes URLs only). A pack_required response means the allowance is exhausted: NOTHING was purchased \u2014 present the pack price (1 credit = $100) and let the user buy from the hub if they want it. 'remove' {sourceId} \u2014 deletes the source AND its indexed content; explicit approval required.",
+    description: "The knowledge base's content sources. action 'list' \u2014 ONE page of sources, most recently ingested first (default 50, max 200 via limit): read `page.has_more`/`next_cursor` and pass cursor to continue \u2014 a page is never the whole library. 'summary' \u2014 exact whole-library counts {total, by_kind, chunks, indexed_chunks, failed_sources, failed_jobs_7d}: use THIS to say what the knowledge base contains, and if failed_jobs_7d > 0 say so \u2014 those ingests are missing from every other count. 'jobs' \u2014 ingest job statuses (optional status filter: queued|running|succeeded|failed). 'add' \u2014 ingest a public page {url} or a whole site {sitemap, since?}; ALWAYS get explicit approval first (ingest costs money and counts against quota), for a local FILE on the user's machine use awesomate_knowledge_upload instead (it streams the file from disk; this tool takes URLs only). A pack_required response means the allowance is exhausted: NOTHING was purchased \u2014 present the pack price (1 credit = $100) and let the user buy from the hub if they want it. 'remove' {sourceId} \u2014 deletes the source AND its indexed content; explicit approval required.",
     inputSchema: {
       action: external_exports.enum(["list", "summary", "add", "remove", "jobs"]),
       url: external_exports.string().url().optional().describe("add: one public page / blog post / YouTube link"),
@@ -41997,7 +41998,7 @@ server.registerTool(
       return knowledgeResult({
         ...result,
         uploaded: { path: abs, filename, sizeBytes: st.size, contentType },
-        note: `Queued \u2014 NOT yet ingested. Poll awesomate_knowledge_sources {action:"jobs"} and read the job's status AND error: a job that fails during processing creates no source row, so summary/failed_sources still look clean and the failure is invisible there. Big media is transcribed and can take a while. Only after the job reports succeeded, verify with awesomate_knowledge_ask before building on it.`
+        note: `Queued \u2014 NOT yet ingested. Poll awesomate_knowledge_sources {action:"jobs"} and read the job's status AND error: a job that fails during processing creates no source row, so summary counts stay clean (only its failed_jobs_7d field shows it). Big media is transcribed and can take a while. Only after the job reports succeeded, verify with awesomate_knowledge_ask before building on it.`
       });
     } catch (err) {
       return knowledgeError(err);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awesomate/hosting-mcp",
-  "version": "0.20.2",
+  "version": "0.20.3",
   "description": "Awesomate MCP server — lets Claude manage your Awesomate WordPress hosting, plan, limits, n8n automations, and build Node/static apps + databases",
   "license": "UNLICENSED",
   "type": "module",

package/skill/CHANGELOG.json

@@ -1,5 +1,11 @@
 {
   "versions": [
+    {
+      "version": "0.20.3",
+      "highlights": [
+        "The Knowledge Base summary now warns when recent uploads failed to ingest - failures used to be invisible unless you checked the jobs list"
+      ]
+    },
     {
       "version": "0.20.2",
       "highlights": [

package/skill/awesomate-knowledge/references/from-your-files.md

@@ -51,8 +51,10 @@ contents never pass through the conversation and a 100 MB PDF costs no context.
 processing never creates a source row, so `{action:'summary'}` still reports
 `failed_sources: 0` and the library total is unchanged. Measured live on
 2026-09-01: an upload failed with a platform error while summary read
-`total: 75, failed_sources: 0`. If you check the summary instead of the job,
-a failed ingest looks exactly like one that was never attempted.
+`total: 75, failed_sources: 0`. On current platforms the summary now carries
+`failed_jobs_7d` + `last_failed_job_at` for exactly this reason — a nonzero
+value means uploads failed that no other count shows; the field is absent on
+older platforms, so its absence proves nothing.
 
 So: read the job's `status` AND its `error`, and relay the error text to the
 user. Real ones seen in the wild, all platform-side rather than anything wrong