sparkroom.list_documentsRead paginated company-library document and latest revision metadata for selecting room contents. Upload files in SparkLaunch.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| category | No | ||
| project_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful behavioral context beyond those annotations: pagination, company-library scope, and latest-revision metadata exposure. It does not discuss authentication or rate limits, but the annotation coverage lowers the burden and the added context is meaningful.
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 with no filler. The first sentence front-loads the action, resource, and purpose; the second sentence provides a concise routing instruction about uploads. Each sentence earns its place, and the structure is easy for an agent to scan quickly.
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 output schema is present, return values do not need to be described. The description covers purpose, pagination, scope, and the upload alternative. Minor gaps remain around category filtering and the precise relationship between project_id and the company library, but the schema and available param names cover most of that. For a read-only listing tool, this is reasonably 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?
Schema description coverage is 0%, so the description must compensate by explaining parameter semantics. It only alludes to pagination, which loosely maps to limit/offset, and to company-library scope, which maps to project_id. It does not explain the category filter values, the meaning of offset/limit beyond the word 'paginated', or the required project_id relationship. The schema supplies types and constraints, but the description adds only minimal parameter-level value.
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 uses a specific verb ('Read') with a specific resource ('company-library document and latest revision metadata') and names the intended use case ('for selecting room contents'). It clearly distinguishes itself as a read-oriented listing tool from mutation siblings like sparkroom.add_documents or sparkroom.update_item, and it is not a mere restatement of the title.
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 indicates when to use the tool: when selecting room contents by reading company-library documents. It also provides an explicit where-not instruction ('Upload files in SparkLaunch'), steering agents away from using this tool for uploads. However, it does not explicitly name sibling tools or articulate nuanced alternatives for listing documents versus listing rooms or adding items, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Domain prefixes (crm., cap_table., landing.) clearly separate broad modules, and most tools target a specific resource and action. However, within modules there are boundary overlaps—crm.add_contact_note vs crm.log_activity and cap_table.dilution_preview vs cap_table.simulate_raise—where descriptions must be read carefully to avoid a wrong pick.
The dominant pattern is module.verb_noun (e.g., crm.create_lead, cap_table.update_stakeholder), which is clear and readable. But a subset of top-level tools uses object_verb with flat underscores (e.g., shortlink_create, qr_generate, campaign_archive) and one outlier (campaign_stats) breaks the verb pattern, so conventions are mixed.
86 tools is an extreme surface for any single MCP server, well past the 50+ threshold that makes coherent selection impractical. Even though the features span several business domains, this would be far more usable split into focused servers per module.
The covered domains are broadly complete: cap table, CRM, incorporation, landing, projects, sparkroom, tasks, and validation all have read/write workflows with few dead ends. Minor gaps remain (no campaign listing/update, no branding palette delete/update, no contact deletion) but none of them blocks the main product workflows.