Skip to main content
Glama
AlexZai007

figma-unlimited-mcp

by AlexZai007

Find nodes by text

find_nodes
Read-only

Locate nodes on a FigJam page by searching for text or name substrings, avoiding the need to list large boards.

Instructions

Search the current page for nodes whose text or name contains a substring (case-insensitive). Cheaper than listing a large board.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYesSubstring to look for.
typesNoRestrict to these node types.
Behavior4/5

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

Beyond the readOnlyHint annotation, the description adds that matching is case-insensitive and limited to the current page, which is valuable context. It also notes the cost advantage. No contradiction with annotations.

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, front-loaded with the primary action and followed by a cost-benefit note. Every word contributes, with no redundancy or filler.

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

Completeness4/5

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

For a straightforward read-only search tool, the description covers purpose, scope, and use-case context. Without an output schema, a note on return format or pagination would improve completeness, but it's not critical given the low complexity.

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

Parameters3/5

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

The schema describes query and types but not limit. The description adds that query is a case-insensitive substring match on text or name, which helps clarify the query parameter's meaning. However, the limit and types behavior are not addressed, and schema coverage is only 67%.

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 clearly states the tool searches the current page for nodes by text or name substring, case-insensitively. It uses a specific verb ('Search') and resource ('nodes'), and the 'Cheaper than listing a large board' note distinguishes it from list_nodes.

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?

It explicitly frames this as a cost-effective alternative to listing a large board, giving clear context for when to use it. While it doesn't name sibling tools directly, the reference to listing is an implicit alternative, so guidance is present.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AlexZai007/figma-unlimited-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server