senti-mcp-server

Read a draft's indicator sources

list_draft_attachments

Read-only

Read indicator source files embedded in a draft via #resource. Pass a draft ID and optional filename to get attachment source; large attachments are listed by name and size.

Instructions

Read the indicator source files a draft's EA embeds via #resource. draftId is the id field from list_drafts. Pass filename to read at most one attachment whole, by exact name — that is also how to read one the default call had to leave out. Filenames are not guaranteed unique within a draft: if more than one attachment shares the requested name, only the first is returned and notes says how many were skipped. With filename omitted this returns every attachment's source up to a 64 KiB budget and lists the rest by name and size only; notes says whether that happened. THE RESPONSE CAN BE LARGE — up to 64 KiB of source, returned in both content and structuredContent — roughly 33,000 tokens worst case. Use get_draft for the EA's own source, which this tool never returns.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "draftId": "<draftId>"
    },
    "name": "list_draft_attachments"
  }
}

Input Schema

Name	Required	Description	Default
`draftId`	Yes
`filename`	No

Output Schema

Name	Required	Description	Default
`notes`	Yes
`attachments`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.9.0Sep 16, 2026
- removedOutput schema / properties / attachments / items / properties / sourceCode / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / attachments / items / properties / sourceCode / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Addedv2.8.0Aug 22, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail: duplicate filenames return only the first with `notes` indicating skipped count, truncated lists are reported via `notes`, and responses can reach roughly 33,000 tokens. It also clarifies what the tool never returns, which is valuable beyond the structured fields.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, parameter behavior, budget limits, duplicate handling, response size warning, and the sibling alternative. Key operational constraints are front-loaded before the large-response warning.

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 a read tool with two parameters, an output schema, and read-only annotations, the description covers all critical decision factors: how to select an attachment, what happens with duplicates, budget truncation, response size, and the distinction from get_draft. Nothing needed for correct invocation is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries full parameter documentation. It defines `draftId` as the `id` field from list_drafts and explains that `filename` is an exact name used to read a single attachment or one omitted by the default call, including omitted-parameter behavior.

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?

The description opens with a specific verb and resource: 'Read the indicator source files a draft's EA embeds via `#resource`.' It clearly differentiates from the sibling get_draft by stating 'this tool never returns' the EA's own source, so an agent can select it correctly.

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

Usage Guidelines5/5

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

It explicitly explains when to pass `filename` versus omit it, including the exact-name matching behavior and the 64 KiB budget fallback. It also names the alternative for a related need: 'Use get_draft for the EA's own source.'

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

Deploy Server