Onplana

lookup_help_topic

Read-onlyIdempotent

Searches Onplana's product help catalog and returns NAVIGATION PATHS: where a page, tab or project view lives, so paths do not have to be guessed. It answers "where is X" and "what does role Z do" for a specific page, tab or feature. It returns no article text, so it cannot say how a feature is used or which of its settings exist; search_docs returns the step-by-step article body that covers those. Takes a short keyword phrase as query (e.g. "rate cards", "goals", "permissions matrix"); empty returns every page available to the caller. Results are auto-filtered to the caller's org role, so they never include pages the user cannot reach. Each page comes with reach, the clicks that open it starting from the sidebar (for Import: the sidebar item, and the menu on the New Project button of the Projects page); routes are not returned, because a person clicks rather than types an address. SCOPE: this catalog covers navigation (pages and project views), the buttons, tabs and menus on the Projects, Issues, Goals and Workflows pages, the project overflow menu, which is where export lives, the web Gantt's toolbar menus item by item (Schedule holds Recalculate now), and how a few things work (a calendar change and Recalculate now; links and lag in Onplana Schedule). It is still not the full set of available actions, so an empty result means nothing in the catalog matched, which is not evidence that the capability is missing; describe_capabilities is the authoritative list of what is actually callable, including categories not yet loaded. Export-shaped queries also return an exportNote stating plainly which outbound formats exist and which do not.

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

Input Schema

Name	Required	Description	Default
`query`	No	Optional keyword(s) to filter by. Substring-matched against page labels, descriptions, sections, paths, and project-tab names. Omit to list every page available to this caller.

Schema Changelog

Changes observed during successful MCP inspections.

AddedJun 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial context beyond them: results are auto-filtered to the caller's org role so unreachable pages never appear, routes are deliberately not returned, `reach` click-paths are supplied instead, and export-shaped queries append an `exportNote`. It also discloses the catalog's coverage boundary (Projects, Issues, Goals, Workflows, project overflow menu, Gantt toolbar) and that the catalog is not the full action set.

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

Conciseness4/5

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

Front-loaded with purpose and output shape before the disambiguation and scope detail, and every sentence carries information. It runs long, and the SCOPE enumeration of Gantt toolbar menus and calendar specifics is dense enough to risk burying the key routing guidance, costing it the top mark.

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 no output schema, the description correctly carries the burden of describing returns: navigation paths, `reach` click sequences, and `exportNote`. It also closes the loop on the tool's most dangerous failure mode (empty result mistaken for missing capability) by pointing to describe_capabilities. 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 100% and the schema already explains substring matching, but the description adds real value: concrete example phrases ("rate cards", "goals", "permissions matrix") and the explicit empty-string behavior (returns every page available to the caller). That goes beyond the schema's "Omit to list every page" framing.

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?

Opens with a specific verb and resource ("Searches Onplana's product help catalog") and immediately defines the output shape (NAVIGATION PATHS: where a page, tab or project view lives). It explicitly contrasts itself with search_docs and describe_capabilities, so an agent can distinguish it from those siblings without opening any schema.

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?

States the exact questions it answers ("where is X", "what does role Z do") and names the alternatives with their selecting conditions: search_docs for step-by-step article bodies, describe_capabilities for what is actually callable. It also explains what an empty result means and warns against reading it as absence of capability, which is genuine when-not guidance.

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

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