Acrium

Get business note

get_note

Read-onlyIdempotent

One business note in full, by note_id (from search_notes or list_notes) or by its exact title, e.g. a log you keep under a fixed name. Pass one of the two.

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": "get_note"
  }
}

Input Schema

Name	Required	Description
`title`	No	The note's exact title (any case).
`note_id`	No
`project_id`	No	Workspace to work in (from list_projects). Leave out for the default one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the description's contribution is the 'in full' payload hint and the any-case exact-title matching rule. It does not cover not-found behavior or what happens if neither identifier is supplied, leaving those gaps to inference.

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 short sentences, front-loaded with the resource and the two lookup modes, with no filler. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description bears responsibility for return shape; 'one business note in full' gives only a coarse hint. For a simple read this is close to adequate, but the mutual-exclusivity rule and the miss/error case are left unspecified.

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 67% and note_id has no description at all, but the description compensates by stating the key constraint absent from the schema: 'Pass one of the two.' That is a real, non-redundant semantic the schema does not encode (required is empty).

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+resource+scope: fetch one business note in full. It explicitly positions itself against the read paths that produce identifiers (search_notes, list_notes), so an agent can separate it from search_notes/list_notes 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?

Names the alternatives that supply the input ('note_id (from search_notes or list_notes)') and gives a concrete use case ('a log you keep under a fixed name'). It stops short of an explicit 'do not use this to find a note' exclusion, but the routing intent is clear.

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

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