Helium - Student Planner

List notes

list_notes

Read-onlyIdempotent

List the user's notes as plain text: all of them, those matching a query, a class's (its own note and its assignments' and resources'), or the note on one assignment, event, or resource. Returns limit at a time, with total and has_more; pass page for the next.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_notes"
  }
}

Input Schema

Name	Required	Description
`page`	No
`limit`	No
`query`	No	Only notes whose title, text, or linked item matches this text.
`class_id`	No	Only notes on this class itself or its assignments or resources (an id from list_classes).
`event_id`	No	Only the note on this event (an id from list_events).
`resource_id`	No	Only the note on this resource (an id from list_resources).
`assignment_id`	No	Only the note on this assignment (an id from list_assignments).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: results are plain text, returned 'limit at a time, with total and has_more', and 'pass page for the next'. That pagination contract is the main thing an agent would otherwise have to discover by trial, though rate limits or ordering guarantees are not mentioned.

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?

Two sentences, both load-bearing: the first defines scope and the second defines the paging contract. The scoping information is front-loaded and the nested parenthetical about class notes is the only mildly dense part.

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?

With an output schema present, return fields need no elaboration, and the description still supplies the paging loop (page/limit/total/has_more) plus the plain-text nature of the content. For a seven-parameter read tool with rich annotations, nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 71% and the two undescribed parameters, page and limit, are exactly the ones the description explains ('Returns limit at a time ... pass page for the next'). It also restates the class-scope semantics (the class's own note plus its assignments' and resources'), which clarifies an easily-misread filter, so it adds meaning beyond the schema rather than duplicating it.

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 ('List the user's notes') and then enumerates the four distinct scoping modes (all, query-matched, class-wide, single linked item). An agent can immediately tell this is a read-only listing tool for notes, distinct from the sibling list_* tools that target other resources.

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?

The description effectively maps each filter to its use case 'all of them, those matching a query, a class's ... or the note on one assignment, event, or resource', which tells the agent which parameter to reach for. It stops short of stating exclusions or naming an alternative tool, so it is clear context rather than a full when/when-not guide.

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

All Helium - Student Planner 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.