Skip to main content
Glama
SWITCHSCIENCE

mcp-micropython-bridge

micropython_read_file

Read a file from a MicroPython board and return its content as text or base64, with options for encoding, error handling, and timeout.

Instructions

MicroPython ボードのファイルを読み出して返す

Args: path: 読み出すファイルのパス (例: "/main.py") timeout: コード送信から Raw REPL 復帰完了までの全体タイムアウト秒数 encoding: テキストデコードに使うエンコーディング errors: テキストデコード時のエラー処理 as_base64: True のときは content を空にし、content_base64 に base64 を返す

Returns: ok: 読み出しに成功したら True path: 読み出したファイルパス content: テキスト内容。as_base64=True のときは空文字列 content_base64: base64 内容。as_base64=False のときは None size_bytes: 読み出したバイト数 error: エラー時のメッセージ

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
errorsNostrict
timeoutNo
encodingNoutf-8
as_base64No

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
pathYes
errorYes
contentYes
size_bytesYes
content_base64Yes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior2/5

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

アノテーションが皆無のため説明文が挙動開示の全責任を負うが、読み取り専用であること、必要な接続状態、失敗時の挙動(部分的読み取りなど)には触れていない。timeout が「コード送信から Raw REPL 復帰完了まで」という点と as_base64 の切り替え挙動は有用な追加情報だが、全体としては不十分。

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

Conciseness3/5

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

Args セクションは簡潔で構造化されているが、Returns セクションは出力スキーマが既に存在するため冗長で、説明文の役割としては重複している。全体として無駄が多い。

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?

5 パラメータで出力スキーマもある中、パラメータ説明は完備している。しかしアノテーションなしにもかかわらず利用条件や兄弟ツールとの関係が欠けており、エージェントが正しく呼び出すための文脈としては最小限。

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?

スキーマ説明カバレッジが 0% なので説明文が全パラメータを補う必要があり、path の例示、timeout の意味、encoding、errors、as_base64 の挙動をすべて説明している。5 パラメータすべてに意味が与えられており、スキーマを超えた価値がある。

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?

「MicroPython ボードのファイルを読み出して返す」は明確な動詞+リソースで、何をするかは一目でわかる。ただし download_file、read_lines、head_lines、tail_lines など類似の兄弟ツールとの使い分けには一切触れておらず、汎用読み出しである点の差別化がない。

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?

いつ使うべきか、いつ使うべきでないか、どの代替ツールを選ぶべきかの記述が一切ない。download_file や read_lines との関係が不明なため、エージェントは選択に推測を要する。

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