Skip to main content
Glama
Sign In
FlipperTalk

FlipperTalk

by ReconGrunt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

flipper_property_get

Read-only

Read system properties from your Flipper Zero by key prefix, like 'devinfo' or 'pwrinfo', providing structured data without parsing CLI output.

Instructions

Read device properties by key prefix (e.g. 'devinfo', 'pwrinfo'). More structured than parsing CLI output.

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

Input Schema

NameRequiredDescriptionDefault
keyNoKey or prefix; empty for all
portNoSerial port (e.g. COM7, /dev/ttyACM0). Omit when one Flipper is attached.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds limited value by stating it reads properties and is structured. No additional behavioral traits disclosed.

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 core purpose and an example. No wasted words.

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?

For a read tool with 2 parameters and 100% schema coverage, the description is adequate but lacks information about the return format or structure, which is not covered by an output schema.

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?

The schema already describes both parameters (key, port) with 100% coverage. The description adds value by providing example key prefixes ('devinfo', 'pwrinfo') and the hint to omit port when one device is attached.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads device properties by key prefix and provides examples ('devinfo', 'pwrinfo'). It distinguishes from CLI parsing but does not explicitly differentiate from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like flipper_info. The mention of 'more structured than parsing CLI output' hints at an alternative but does not provide clear context or exclusions.

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

Deploy Server

Other Tools