TechFabric

Your drafts

list_drafts

Read-onlyIdempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Lists your drafts (blog posts, case studies and revisions of live posts), newest first: each one's id, title, kind, state (writing, question_for_you, drafted, checks_failing, ready_to_publish, published and the rest), created and updated dates, preview link and next_action. Filter by state, kind and creation date (created_after, created_before: "yesterday" is the day before the answer's today), and page with cursor. The editor may pass all for everyone's; the site owner, stale: true for his owner queue (drafts stuck over two days). Reads only. Then get_status with an id for one draft in detail.

Input Schema

Name	Required	Description
`all`	No	The blog's editor only: everyone's drafts, not just yours. Refused for anyone else
`kind`	No	Only this kind: post, case-study, or revision (of a live post). Leave it out for all
`limit`	No	How many to return, newest first (default 20)
`stale`	No	The site owner only, his owner queue: everyone's drafts with nothing from their author for more than two days (stuck, a question for them, held, drafted or failing checks; never an agent's explainer), oldest wait first. "Show my owner queue" is this. Refused for anyone else
`state`	No	Only drafts in this state: writing, preview_building, question_for_you, drafted, checking, checks_failing, ready_to_publish, publishing, published, stuck, closed; or open, every one not yet published or closed; or stale, the site owner's queue (as stale: true). Leave it out for all
`cursor`	No	The next_cursor from the previous page, with the same filters
`created_after`	No	Only drafts created at or after this: a date (YYYY-MM-DD, midnight UTC) or an ISO 8601 time with its offset. For yesterday: created_after yesterday's date and created_before today's (the answer's today is the server's date, UTC; pass times with the engineer's offset for their own day)
`created_before`	No	Only drafts created before this (not at it): a date (YYYY-MM-DD, midnight UTC) or an ISO 8601 time

Output Schema

Name	Required	Description
`next`	Yes
`count`	Yes
`scope`	Yes
`today`	Yes	The server's date (UTC), to work out yesterday from
`total`	Yes	How many drafts match, over every page
`drafts`	Yes
`filters`	No
`partial`	No	Present when some drafts' states came from their records because their check runs could not all be read
`next_cursor`	Yes	Pass as cursor for the next page; null on the last

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 22, 2026

addedInput schema / properties / stale

Added value: +{
+  "description": "The site owner only, his owner queue: everyone's drafts with nothing from their author for more than two days (stuck, a question for them, held, drafted or failing checks; never an agent's explainer), oldest wait first. \"Show my owner queue\" is this. Refused for anyone else",
+  "type": "boolean"
+}

changedInput schema / properties / state / description

Previous value: -"Only drafts in this state: writing, preview_building, question_for_you, drafted, checking, checks_failing, ready_to_publish, publishing, published, stuck, closed; or open, every one not yet published or closed. Leave it out for all"New value: +"Only drafts in this state: writing, preview_building, question_for_you, drafted, checking, checks_failing, ready_to_publish, publishing, published, stuck, closed; or open, every one not yet published or closed; or stale, the site owner's queue (as stale: true). Leave it out for all"

changedInput schema / properties / state / enum

Previous value: -[
-  "writing",
-  "preview_building",
-  "question_for_you",
-  "drafted",
-  "checking",
-  "checks_failing",
-  "ready_to_publish",
-  "publishing",
-  "published",
-  "stuck",
-  "closed",
-  "open"
-]New value: +[
+  "writing",
+  "preview_building",
+  "question_for_you",
+  "drafted",
+  "checking",
+  "checks_failing",
+  "ready_to_publish",
+  "publishing",
+  "published",
+  "stuck",
+  "closed",
+  "open",
+  "stale"
+]

addedOutput schema / properties / drafts / items / properties / owner_queue

Added value: +{
+  "description": "Only with stale: true: why it is in the owner queue",
+  "properties": {
+    "author_last_active": {
+      "type": "string"
+    },
+    "days_waiting": {
+      "type": "integer"
+    },
+    "reason": {
+      "description": "The one-line reason, from its record",
+      "type": "string"
+    },
+    "state": {
+      "enum": [
+        "stuck",
+        "question_for_you",
+        "held",
+        "checks_failing",
+        "drafted"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / scope / enum

Previous value: -[
-  "yours",
-  "everyone"
-]New value: +[
+  "yours",
+  "everyone",
+  "owner_queue"
+]

AddedOct 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive behavior; the description adds the Microsoft sign-in requirement and blog.write scope, plus ordering ('newest first') and that it 'Reads only'. It does not cover response format or rate limits, but with annotations and an output schema those are less critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one dense, run-on sequence with nested parentheticals, making it harder to scan than necessary. Much of the state and field enumeration duplicates the 100%-covered schema, though the auth note and sibling pointer are front-loaded and useful.

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?

For an eight-parameter, permission-sensitive list tool, the description covers auth scope, role-gated parameters, filtering, cursor pagination, ordering and the follow-up get_status call. With an output schema and rich annotations already present, nothing an agent needs to invoke this correctly appears missing.

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?

Schema description coverage is 100%, so the schema already documents all eight parameters, including the editor-only and owner-only refusal semantics. The description's parameter text largely mirrors the schema, adding little beyond the baseline for full schema coverage.

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 ('Lists your drafts') and scopes it to drafts including blog posts, case studies and revisions. It also distinguishes itself from get_status by telling the agent to use get_status for one draft in detail, so it is separable from a sibling without opening schemas.

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

Usage Guidelines4/5

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

Gives clear operating context: filter by state/kind/date, page with cursor, editor-only 'all', site-owner-only 'stale', and 'Then get_status with an id for one draft in detail'. It does not explicitly rule out list_posts or other siblings, but the draft-scoped usage is clear.

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

All TechFabric 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.