あなたの医療記録はGmail、Googleドライブ、カレンダーに散らばっていませんか？Oncofilesはそれらすべてを読み込み、整理し、AIを通じて利用可能にします。これにより、ClaudeやChatGPTで自分の健康状態について自然な言葉で質問できるようになります。
oncofiles.com | デモダッシュボード | プライバシーポリシー
Oncofilesは、がん患者とその介護者のために構築されたMCPサーバーです。Googleドライブ、Gmail、カレンダーに接続し、すべての医療文書（検査結果、CTスキャン、病理レポート、処方箋など）を読み込み、Claude、ChatGPT、または任意のMCPクライアントといったAIチャットを通じてアクセス可能にします。
切実なニーズから誕生： 妻のがん治療を管理する介護者によって作成されました。何百もの文書、何十人もの医師、絶えず変化する検査結果。Oncofilesは、書類探しではなく治療に集中できるよう、その混沌を整理します。
姉妹プロジェクト： Oncoteam — Oncofilesのデータを分析するAIエージェントです。検査値の傾向を追跡し、臨床試験を検索し、腫瘍内科医への質問を準備します。
データはあなたの管理下に： すべてのデータはGoogleドライブ内に留まります。サードパーティによるデータ処理は行われません。いつでも接続を解除でき、ファイルは常にあなたのものです。
Related MCP server: atlas_mcp
Oncofilesは、単一のインスタンスで複数の患者をサポートします。各患者には以下が提供されます：
完全なデータ分離 — 文書、検査結果、治療イベント、メール、カレンダーの予定は患者ごとにスコープされます
個別のベアラートークン — 各患者（または介護者）は独自の onco_* トークンを取得します
患者ごとのOAuth — Googleドライブ、Gmail、カレンダーは患者ごとに認証されます
ダッシュボードの患者セレクター — Webダッシュボードで患者を切り替え可能です
ダッシュボードウィザード： ダッシュボードを開き、「+ 新規患者」をクリックして、4ステップのウィザードに従います
API： {patient_id, display_name} を指定して POST /api/patients を実行 — ベアラートークンが返されます
GDrive接続： /oauth/authorize/drive?patient_id=X にアクセスして文書同期を承認します
初回同期のトリガー： {patient_id} を指定して POST /api/sync-trigger を実行し、文書をインポートします
14モジュール、76のMCPツールによる包括的な医療データ管理
14の文書カテゴリ — 検査、病理、画像、遺伝学、手術、診察、処方箋など
検査値の追跡 — 値の保存、傾向の追跡、化学療法プロトコルのためのサイクル前安全チェック
Googleドライブ同期 — 自動OCRコンパニオンファイルによる双方向同期
Gmailとカレンダーのスキャン — 医療関連のメールや予約を自動検出し分類
臨床研究 — PubMedおよびClinicalTrials.govの検索、研究決定の記録
治療タイムライン — 化学療法サイクル、手術、その他の治療イベントの追跡
文書のバージョン管理 — 完全な履歴による文書リビジョンの追跡
AIによるメタデータ — 自動要約、タグ付け、構造化データ抽出
監査ログ — 説明責任を果たすため、すべてのツール呼び出しをログに記録
┌─────────────────┐ MCP Protocol ┌──────────────┐
│ Claude / GPT │◄────────────────────► │ Oncofiles │
│ (AI Assistant) │ streamable-http │ MCP Server │
└─────────────────┘ └──────┬───────┘
│
┌─────────────┼─────────────┐
│ │ │
┌─────▼─────┐ ┌────▼────┐ ┌─────▼─────┐
│ SQLite / │ │ Google │ │ Anthropic │
│ Turso │ │ Drive │ │ Files API │
└───────────┘ └─────────┘ └───────────┘スタック： Python 3.12+ · FastMCP 3.1 · Pydantic · SQLite/Turso · Railway
# Clone and install
git clone https://github.com/peter-fusek/oncofiles.git
cd oncofiles
uv sync --extra dev
# Run locally (stdio mode for Claude Desktop)
uv run oncofiles-mcp
# Run tests
uv run pytest
# Lint
uv run ruff check# Required
DATABASE_PATH=data/oncofiles.db
# Optional — cloud database
TURSO_DATABASE_URL=libsql://...
TURSO_AUTH_TOKEN=...
# Optional — Google Drive sync
GOOGLE_DRIVE_FOLDER_ID=...
GOOGLE_OAUTH_CLIENT_ID=...
GOOGLE_OAUTH_CLIENT_SECRET=...
# Optional — remote access
MCP_TRANSPORT=streamable-http # default: stdio
MCP_HOST=0.0.0.0
MCP_PORT=8080
MCP_BEARER_TOKEN=...Claude Desktopの設定（~/Library/Application Support/Claude/claude_desktop_config.json）に追加します：
{
"mcpServers": {
"oncofiles": {
"command": "uv",
"args": ["run", "oncofiles-mcp"],
"cwd": "/path/to/oncofiles"
}
}
}OncofilesはChatGPTのMCP統合（開発者モード）で動作します。ChatGPTの接続先を、ベアラートークンを使用したインスタンスの /mcp エンドポイントに設定してください。
同梱の Dockerfile はRailwayデプロイに対応しています：
GitHubにプッシュ
Railwayでリポジトリを接続
環境変数を設定
プッシュ時にRailwayが自動デプロイ
ライブインスタンス：oncofiles.com
src/oncofiles/
├── server.py # FastMCP server, auth, routes, scheduler
├── database/ # Mixin-based DB layer (SQLite/Turso)
├── tools/ # 14 tool modules (76 tools)
│ ├── documents.py # CRUD, search, view, versioning
│ ├── lab_trends.py # Lab values, trends, safety checks
│ ├── clinical.py # Treatment events, research log
│ ├── research.py # PubMed, ClinicalTrials.gov search
│ └── ...
├── sync.py # Bidirectional Google Drive sync
├── gmail_sync.py # Medical email detection and import
├── calendar_sync.py # Calendar event classification
├── enhance.py # AI metadata extraction (Haiku)
├── patient_middleware.py # Per-patient token → context resolution
├── patient_context.py # Patient clinical profile
└── models.py # Pydantic modelsMCPレジストリ に io.github.peter-fusek/oncofiles として登録されています。
ガイドラインについては CONTRIBUTING.md を参照してください。
Peter Fusek — CEO & 創設者
シリアルアントレプレナーでありAIストラテジスト。Tatra bankaで4年間勤務。marketlocatorを共同設立（Deutsche Telekomへ売却）。VÚB銀行CEOのアドバイザー。18年以上にわたり技術製品を構築。
妻のがん治療において、何百もの文書、何十人もの医師、絶えず変化する検査結果を管理するという個人的な経験からOncofilesを構築。
LinkedIn · peter.fusek@instarea.com
Peter Čapkovič — CTO & 共同創設者
エンタープライズバンキング（VÚB）で20年以上の経験を持つシニアITアーキテクト。.NET、Python、SQL、システムアーキテクチャの専門家。Instareaの全製品のアーキテクチャを主導。
アーキテクチャ、開発、運用を統括。
Instarea — 18年の歴史、23製品をリリース。テレコム分析やエンタープライズクライアント（Callinspector）から、モバイルファーストのフィンテック（InventButton）、ビッグデータ売却（marketlocator → Deutsche Telekom）、IoTプラットフォーム、AIファースト製品（PulseShape, ReplicaCity, HomeGrif）まで幅広く展開。
OncofilesとOncoteamはInstareaの最新製品であり、銀行、テレコム、データ業界向けのエンタープライズグレード製品を提供してきたのと同じエンジニアリング規律に基づいて構築されています。
フロントエンド、バックエンド、統合、データサイエンス、UX/UI、マーケティング、クラウド運用にわたる10名以上の検証済みチームメンバーが在籍。
「私たちは、家族や仕事と同じように、自分たちの顔が見える形で個人的に取り組んでいます。」
Log an agent tool call to the activity audit trail (append-only).
Args: session_id: Session identifier. agent_id: Agent that made the call (e.g. oncoteam). tool_name: Name of the tool that was called. input_summary: Brief summary of the input parameters. output_summary: Brief summary of the output. duration_ms: How long the call took in milliseconds. status: Result status (ok, error, timeout). error_message: Error details if status is not ok. tags: JSON array of tags (e.g. '["research","pubmed"]').
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| agent_id | Yes | ||
| tool_name | Yes | ||
| input_summary | No | ||
| output_summary | No | ||
| duration_ms | No | ||
| status | No | ok | |
| error_message | No | ||
| tags | No | [] |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying this is 'append-only' (important behavioral constraint) and describing what gets logged. It doesn't mention authentication requirements, rate limits, or error handling beyond the status parameter, but provides solid operational context for a logging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with a clear purpose statement followed by well-organized parameter explanations. Every sentence earns its place, with no redundant information. The formatting with 'Args:' section makes it easily scannable while remaining comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 3 required), zero schema description coverage, and no annotations, the description provides complete context. It explains the tool's purpose, all parameters with semantics, and behavioral constraints ('append-only'). With an output schema present, it appropriately doesn't explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides clear, meaningful explanations for all 9 parameters, including examples (e.g., 'e.g. oncoteam', 'e.g. "[\"research\",\"pubmed\"]"'), default behaviors, and purpose for each field, adding substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Log an agent tool call') and resource ('to the activity audit trail'), with the parenthetical '(append-only)' providing important context about the operation's nature. It distinguishes this from sibling tools like 'search_activity_log' or 'get_activity_stats' by focusing on creation rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the parameter explanations (e.g., 'Agent that made the call'), suggesting this is for recording tool usage after execution. However, it doesn't explicitly state when to use this tool versus alternatives like 'log_conversation' or provide clear prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a research article or clinical trial found by an agent.
Deduplicates by source+external_id — if a duplicate is found, returns the existing entry without error.
Args: source: Source name (e.g. pubmed, clinicaltrials). external_id: External identifier (e.g. PMID, NCT number). title: Article or trial title. summary: Brief summary or abstract excerpt. tags: JSON array of tags (e.g. '["FOLFOX","mCRC"]'). raw_data: Full raw data (abstract, JSON, etc.) for reference.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| external_id | Yes | ||
| title | Yes | ||
| summary | No | ||
| tags | No | [] | |
| raw_data | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: the deduplication logic ('Deduplicates by source+external_id'), the non-error response to duplicates ('returns the existing entry without error'), and the purpose ('Save... for reference'). It doesn't mention permissions, rate limits, or mutation consequences, but covers the core operation adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a purpose statement, behavioral note, and parameter documentation in bullet points. Every sentence adds value with no redundancy, and it's appropriately sized for a tool with 6 parameters and important behavioral nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (mentioned in context signals), the description doesn't need to explain return values. It covers purpose, behavior, and parameters well for a creation/deduplication tool. The only minor gap is lack of explicit error cases or prerequisites, but overall it's quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear semantic explanations for all 6 parameters with examples (e.g., 'e.g. pubmed, clinicaltrials', 'e.g. PMID, NCT number', 'JSON array of tags'), going well beyond the bare schema to explain what each parameter represents and how to format them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Save a research article or clinical trial found by an agent') and identifies the resource ('research entry'). It distinguishes itself from sibling tools like 'list_research_entries' and 'search_research' by focusing on creation/deduplication rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('found by an agent') and mentions deduplication behavior, which helps differentiate it from simple creation tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a treatment milestone (chemo cycle, surgery, scan result, etc.).
Args: event_date: Date of the event (YYYY-MM-DD). event_type: Type of event (e.g. chemo, surgery, scan, consult, side_effect). title: Short title for the event. notes: Optional longer description or notes. metadata: Optional JSON string with extra structured data.
| Name | Required | Description | Default |
|---|---|---|---|
| event_date | Yes | ||
| event_type | Yes | ||
| title | Yes | ||
| notes | No | ||
| metadata | No | {} |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states 'Record' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether this creates a new record or updates existing ones, error conditions, or what the output contains. The description is minimal beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence states the purpose clearly, followed by a well-organized 'Args:' section that documents each parameter efficiently. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 5 parameters with 0% schema coverage, and no annotations, the description does well by explaining all parameters semantically. However, it could provide more behavioral context about the mutation operation. For a write tool with no annotations, it's mostly complete but has room for improvement on behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all 5 parameters beyond just their names, explaining what each represents (e.g., 'Date of the event', 'Type of event', 'Short title', etc.) and which are optional. This adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Record a treatment milestone') and resource ('treatment milestone'), with concrete examples (chemo cycle, surgery, scan result, etc.). It effectively distinguishes from sibling tools like 'add_activity_log' or 'add_research_entry' by focusing on medical treatment events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording medical treatment events, but doesn't explicitly state when to use this tool versus alternatives like 'update_treatment_event' or 'delete_treatment_event'. It provides context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze recent lab results with oncology context.
Downloads lab documents and returns them inline for Claude to read, along with patient context for interpreting results under chemotherapy.
Note: Each lab document is 100KB-2MB. Keep limit low to avoid large responses.
Args: file_id: Specific lab file_id to analyze. If omitted, fetches the most recent labs. limit: Maximum number of lab documents to include (default 3).
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that the tool downloads lab documents (100KB-2MB each), returns them inline for Claude to read, includes patient context, and advises keeping limits low to avoid large responses. This covers key operational traits beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by behavioral notes and parameter details. Every sentence adds value—no wasted words—and it's appropriately sized for a tool with two parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and no output schema, the description does a good job explaining inputs, behavior, and context. It could be more complete by detailing the output format or error handling, but it covers the essentials for a read-oriented tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'file_id' (specific lab to analyze or omitted for recent labs) and 'limit' (maximum documents, default 3). This adds meaningful semantics beyond the bare schema, though it could provide more detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze recent lab results with oncology context.' It specifies the verb ('analyze'), resource ('lab results'), and domain context ('oncology'). However, it doesn't explicitly differentiate from sibling tools like 'compare_labs' or 'get_lab_summary,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('under chemotherapy') and provides parameter guidance (e.g., 'If omitted, fetches the most recent labs'), but it doesn't explicitly state when to use this tool versus alternatives like 'compare_labs' or 'get_lab_summary.' The guidance is helpful but incomplete for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start Calendar authorization flow. Returns a URL the user must visit.
After visiting the URL and completing Google's consent screen, Calendar read access will be enabled. Call integration_status() to verify.
WARNING: This grants read access to ALL events in Google Calendar.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns a URL for user interaction, requires a follow-up call to verify completion, and includes a critical warning about granting read access to ALL events. This covers authentication flow, side effects, and security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each add value: stating the purpose, describing the return value and user action, specifying verification steps, and providing a critical warning. There's no redundant information, and the warning is appropriately placed for emphasis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (authentication flow with security implications), no annotations, and an output schema (implied by 'Returns a URL'), the description is complete. It explains what the tool does, what happens after use, how to verify completion, and includes essential security warnings, covering all necessary context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and behavior. A baseline of 4 is given since no parameters exist, and the description doesn't introduce unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start Calendar authorization flow') and resource ('Calendar read access'), distinguishing it from sibling tools like gmail_auth_enable or gdrive_auth_url. It explicitly mentions Google Calendar, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Start Calendar authorization flow') and what to do after ('Call integration_status() to verify'). It distinguishes this from other auth-related tools by specifying it's for Calendar, not Gmail or Drive, and includes a prerequisite warning about the scope of access granted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare lab values between two dates side-by-side.
Returns all parameters measured on both dates with change direction, absolute delta, percentage change, and out-of-range flags.
Args: date_a: First date (YYYY-MM-DD), typically the earlier measurement. date_b: Second date (YYYY-MM-DD), typically the later measurement.
| Name | Required | Description | Default |
|---|---|---|---|
| date_a | Yes | ||
| date_b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by detailing the return format ('all parameters measured on both dates with change direction, absolute delta, percentage change, and out-of-range flags'), which clarifies what the tool does beyond basic comparison. However, it lacks information on permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and the second detailing the return format, followed by a concise parameter explanation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is complete enough. It explains the purpose, behavior, and parameter semantics, and since an output schema exists, it does not need to detail return values, making it well-rounded for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'date_a' is 'typically the earlier measurement' and 'date_b' is 'typically the later measurement', providing context and usage hints that are not captured in the schema's bare string types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('compare lab values') and resources ('between two dates side-by-side'), distinguishing it from siblings like 'analyze_labs' or 'get_lab_time_series' by focusing on side-by-side comparison rather than analysis or time-series retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'typically the earlier measurement' and 'typically the later measurement' for date parameters, but does not explicitly state when to use this tool versus alternatives like 'compare_labs' or 'get_lab_trends', nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare lab results over time to identify trends.
Two modes:
Specific: provide file_id_a and file_id_b to compare two specific lab sets.
Date range: provide date_from/date_to to compare all labs in a period.
Note: Each lab document is 100KB-2MB. Keep limit reasonable.
Args: file_id_a: First lab file_id (optional). file_id_b: Second lab file_id (optional). date_from: Start date for range query (YYYY-MM-DD). date_to: End date for range query (YYYY-MM-DD). limit: Maximum number of lab documents to include (default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| file_id_a | No | ||
| file_id_b | No | ||
| date_from | No | ||
| date_to | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behavioral traits: the tool has two operational modes, handles large documents (100KB-2MB), and has a default limit of 10 documents. However, it doesn't disclose whether this is a read-only operation, what permissions are required, how results are formatted, or potential rate limits. The description adds useful context but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, mode explanation, size warning, and parameter definitions. It's appropriately sized for a 5-parameter tool with multiple operational modes. Some sentences could be more concise (e.g., 'provide file_id_a and file_id_b to compare two specific lab sets' could be simplified), but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no output schema, the description does a good job explaining parameters and usage modes. However, for a comparison tool with no annotations, it should ideally describe the output format (what the comparison results look like) and any error conditions. The size warning is helpful, but more behavioral context would improve completeness for this moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters, the description fully compensates by providing clear semantic explanations for all parameters. It explains the purpose of file_id_a/file_id_b for specific comparisons, date_from/date_to for range queries, and limit for controlling result size. The description adds substantial value beyond the bare schema, clarifying how parameters interact in different modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare lab results over time to identify trends.' It specifies the resource (lab results) and verb (compare), but doesn't explicitly differentiate from sibling tools like 'compare_lab_panels' or 'get_lab_trends' which might have overlapping functionality. The purpose is clear but sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by outlining two modes (specific vs. date range) and specifying parameter combinations. It mentions a size constraint ('Each lab document is 100KB-2MB. Keep limit reasonable.') which helps inform usage decisions. However, it doesn't explicitly state when to use this tool versus alternatives like 'compare_lab_panels' or 'get_lab_trends' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-delete a document (moves to trash, recoverable for 30 days).
The document is hidden from all listings and searches but can be restored using restore_document. Files API copy is also deleted.
Args: file_id: The Anthropic Files API file_id to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the operation is a soft-delete (not permanent), moves the document to trash, is recoverable for 30 days, hides it from listings and searches, and deletes the Files API copy. This covers mutation effects, reversibility, and side effects, though it lacks details on permissions or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core action and key details (soft-delete, trash, recoverable), followed by additional behavioral context, and ends with a clear parameter explanation. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with behavioral nuances), no annotations, and an output schema present (which handles return values), the description is largely complete. It covers purpose, behavior, and parameters well. However, it could improve by mentioning prerequisites (e.g., authentication) or error cases, though the output schema may mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by explaining the single parameter 'file_id' as 'The Anthropic Files API file_id to delete,' adding crucial semantic context beyond the schema's type information. This clarifies the parameter's purpose and format, making it highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('soft-delete a document'), the resource affected ('document'), and distinguishes it from siblings by specifying it moves to trash and is recoverable for 30 days. It explicitly contrasts with 'restore_document' for recovery, making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to soft-delete a document) and mentions 'restore_document' as the alternative for recovery, which helps differentiate from permanent deletion. However, it does not explicitly state when not to use it (e.g., vs. hard delete or other deletion methods), nor does it compare to all sibling tools like 'delete_treatment_event'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a treatment event by ID. Use for removing contaminated/test data.
Args: event_id: The treatment event ID to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't mention permissions, reversibility, side effects, or confirmation steps. For a destructive tool, this is insufficient to ensure safe usage by an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a clear parameter explanation in a structured format. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, and an output schema (which may cover return values), the description is minimally adequate. It explains the action and parameter but lacks critical behavioral details like safety warnings or error handling, making it incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the single parameter ('event_id: The treatment event ID to delete'), adding meaning beyond the bare schema. However, it doesn't specify format constraints (e.g., valid ID ranges or sources), leaving minor gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('treatment event by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_document' or 'update_treatment_event', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context ('Use for removing contaminated/test data'), which implies when to use it, but lacks explicit guidance on when not to use it or alternatives (e.g., vs. updating or archiving). No sibling tool comparisons are mentioned, leaving gaps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run AI enhancement (summary + tags) on documents.
If document_ids is omitted, processes all documents that haven't been enhanced yet.
Args: document_ids: Comma-separated document IDs to enhance. If omitted, enhances all unprocessed.
| Name | Required | Description | Default |
|---|---|---|---|
| document_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs 'AI enhancement' but doesn't specify what that entails beyond 'summary + tags'—e.g., whether it's a read-only operation, if it modifies documents, requires permissions, has rate limits, or what happens on errors. For a tool that likely involves AI processing and document updates, this lack of detail is a significant gap, though it's not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by conditional usage and parameter details in a structured 'Args:' section. Every sentence adds value without redundancy, making it efficient and easy to parse. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), the description doesn't need to explain outputs. However, with no annotations and a single parameter, it adequately covers purpose and usage but lacks behavioral details (e.g., side effects, error handling). For an AI enhancement tool, this leaves gaps in understanding how it interacts with documents, making it minimally complete but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'document_ids': it explains that it's 'comma-separated document IDs to enhance' and clarifies the default behavior when omitted ('enhances all unprocessed'). Since schema description coverage is 0% (the schema only defines the type without descriptions), this compensates well, providing clear semantics beyond the bare schema. With 0 parameters effectively documented in the schema, the description does a good job, but could note format specifics (e.g., ID examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run AI enhancement (summary + tags) on documents.' It specifies the verb ('Run AI enhancement'), resource ('documents'), and what the enhancement includes ('summary + tags'). However, it doesn't explicitly distinguish this tool from potential siblings like 'analyze_labs' or 'qa_analysis', which might also involve AI processing, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'If document_ids is omitted, processes all documents that haven't been enhanced yet.' This gives explicit guidance on the default behavior. However, it doesn't mention when not to use it or name alternatives among the sibling tools (e.g., 'extract_document_metadata' might be related), so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a structured document package for consultations or second opinions.
Assembles all documents grouped by category with metadata, treatment events timeline, and structured metadata. Returns JSON that Oncoteam can render as PDF, email, or share link.
Args: include_metadata: Include AI summaries and structured metadata (default True). include_timeline: Include treatment events timeline (default True).
| Name | Required | Description | Default |
|---|---|---|---|
| include_metadata | No | ||
| include_timeline | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'Assembles all documents grouped by category' and returns JSON for rendering, which gives some behavioral context. However, it lacks details on permissions, side effects, rate limits, or error handling, which are important for a tool that likely accesses sensitive data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by details on output and parameters. It uses bullet points for parameters efficiently. A minor deduction because the first sentence could be more front-loaded with key actions, but overall it's concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (exporting structured data with parameters) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, output format, and parameter semantics. However, it lacks usage guidelines and some behavioral details, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explicitly explains both parameters ('include_metadata' and 'include_timeline') with their purposes and default values, fully compensating for the schema's lack of documentation. This is essential for understanding what these boolean flags control.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export a structured document package for consultations or second opinions.' It specifies the verb ('Export') and resource ('structured document package') with context about its use case. However, it doesn't explicitly differentiate from sibling tools like 'export_manifest' or 'extract_all_metadata', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the tool's purpose but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'export_manifest' or document-related tools. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the full database as a JSON manifest (on-demand).
Returns the manifest JSON with all documents, conversations, treatment events, research entries, and agent state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool exports data and returns JSON, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, potential performance impacts, authentication requirements, rate limits, or whether it modifies data. For a tool that likely involves significant data retrieval, this is a notable gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the action and context ('on-demand'), the second details the return content. Every word adds value without repetition or fluff. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input parameters, an output schema exists, and no annotations, the description covers the basic purpose and return data types adequately. However, for a tool that exports the entire database, it lacks context about potential side effects, performance considerations, or usage constraints that would be important for an AI agent. The output schema may detail the JSON structure, but behavioral completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input (none required). The description appropriately doesn't add parameter details, as there are none to explain. It focuses on the tool's purpose and output instead, which is correct for this case. Baseline would be 4 for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the full database as a JSON manifest, specifying the action (export) and resource (full database). It distinguishes from siblings like export_document_package by emphasizing 'full database' and listing included data types (documents, conversations, treatment events, research entries, agent state). However, it doesn't explicitly contrast with all potential alternatives, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'on-demand' and by listing the data types included, suggesting this is for comprehensive data export. However, it doesn't provide explicit guidance on when to use this versus alternatives like export_document_package or query_db, nor does it mention prerequisites or exclusions. The context is implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backfill structured_metadata for all documents that have AI summaries but no metadata.
Scans for documents where ai_processed_at is set but structured_metadata is empty, then extracts structured metadata from cached OCR text. Useful after adding the structured_metadata column to an existing database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: scanning documents based on specific criteria and extracting metadata from cached OCR text. However, it lacks details on permissions needed, potential side effects (e.g., data modification), rate limits, or error handling, which are important for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: it states the purpose, explains the scanning criteria and extraction process, and provides usage context. Every sentence adds value without redundancy, making it front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch metadata extraction), no annotations, and an output schema present, the description is mostly complete. It covers the what, why, and how, but could benefit from more behavioral details like safety or performance considerations. The output schema likely handles return values, so the description doesn't need to explain them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately explains the tool's operation without referencing parameters, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to 'backfill structured_metadata for all documents that have AI summaries but no metadata' by scanning for documents with 'ai_processed_at' set but empty 'structured_metadata' and extracting metadata from cached OCR text. It specifies the exact conditions and mechanism, distinguishing it from siblings like 'extract_document_metadata' which likely handles individual documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'after adding the structured_metadata column to an existing database' and for documents with AI summaries but no metadata. However, it does not explicitly state when not to use it or name alternatives (e.g., 'extract_document_metadata'), though the context implies it's for batch processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and store structured medical metadata from a document.
Uses AI to analyze the document text and extract findings, diagnoses, medications, providers, and a patient-friendly summary. Results are persisted in the structured_metadata column.
Args: document_id: The local document ID to extract metadata from.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that results are 'persisted in the structured_metadata column', indicating a write operation, but lacks details on permissions required, whether the operation is idempotent, error handling, or performance characteristics. For a tool that modifies data, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by details. The 'Args' section is structured but slightly verbose; every sentence adds value, though it could be more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (AI analysis, metadata extraction, persistence) and the presence of an output schema (which covers return values), the description is reasonably complete. It explains the process and parameter semantics well, though it lacks behavioral context like error cases or side effects, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the single parameter ('document_id: The local document ID to extract metadata from'), adding meaning beyond the input schema's basic type definition. Since schema description coverage is 0%, this compensates well, though it doesn't specify format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('extract and store') and resource ('structured medical metadata from a document'), distinguishing it from siblings like 'extract_all_metadata' by focusing on medical metadata and persistence. It explicitly mentions the AI analysis and specific metadata types (findings, diagnoses, medications, providers, patient-friendly summary), providing comprehensive detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'extract_all_metadata' or 'enhance_documents', nor does it mention prerequisites or exclusions. It only states what the tool does without contextual usage instructions, leaving the agent to infer when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch clinical trials from ClinicalTrials.gov and store in research_entries.
Searches the ClinicalTrials.gov API v2 for matching studies and saves them to the research_entries table (deduplicates by NCT number).
Args: condition: Medical condition to search for (e.g. "colorectal cancer"). keywords: Additional search terms (e.g. "FOLFOX", "immunotherapy"). status: Trial status filter (RECRUITING, ACTIVE_NOT_RECRUITING, COMPLETED). location_country: Country filter (e.g. "United States", "Slovakia"). phase: Phase filter (PHASE1, PHASE2, PHASE3, PHASE4). limit: Maximum number of trials to fetch (default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | ||
| keywords | No | ||
| status | No | RECRUITING | |
| location_country | No | ||
| phase | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: fetching from an external API (ClinicalTrials.gov v2), storing to a database table (research_entries), and deduplication by NCT number. However, it lacks details on error handling, rate limits, authentication needs, or what happens if storage fails. For a tool with external API calls and database writes, more behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a high-level summary, then details the process, and finally lists parameters with explanations. Every sentence earns its place: the first sentence states the core action, the second explains the search and storage logic, and the parameter section provides essential usage details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API fetch + database storage, 6 parameters, no annotations), the description is mostly complete. It covers purpose, usage, parameters, and key behaviors like deduplication. However, with no annotations and an output schema present (though not shown here), it could benefit from mentioning response format or error cases. Still, it provides enough context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides clear semantics for all 6 parameters: 'condition' (medical condition to search), 'keywords' (additional search terms), 'status' (trial status filter with examples), 'location_country' (country filter), 'phase' (phase filter with examples), and 'limit' (maximum number with default). This adds significant value beyond the bare schema, explaining what each parameter means and providing examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('fetch', 'store', 'search', 'save') and resources ('clinical trials from ClinicalTrials.gov', 'research_entries table'). It distinguishes this tool from siblings like 'search_research' or 'list_research_entries' by specifying it fetches from an external API and stores results locally with deduplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to fetch and store clinical trials from ClinicalTrials.gov) but doesn't explicitly state when not to use it or name alternatives. For example, it doesn't compare to 'search_research' (which might search locally) or 'add_research_entry' (which might add manually). However, the context is clear enough for an agent to understand its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect potential duplicate documents based on original filename and file size.
Returns groups of documents that share the same original_filename + size_bytes. Each group contains 2+ documents. Useful for cleanup after repeated imports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it detects duplicates based on specific criteria and returns groups, which is useful. However, it does not mention potential side effects (e.g., whether it modifies data, requires permissions, or has rate limits), leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage. Every sentence earns its place: the first explains what the tool does and its criteria, and the second clarifies the output and context, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple detection with no inputs), no annotations, and an output schema (implied by 'Has output schema: true'), the description is mostly complete. It explains the detection logic and use case, but since no annotations exist, it could benefit from more behavioral details (e.g., safety or performance). The output schema likely covers return values, reducing the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate since no parameters exist. Baseline for 0 parameters is 4, as the description need not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detect potential duplicate documents') and resources ('documents'), and distinguishes it from siblings by focusing on duplicate detection based on filename and size. It explicitly mentions the criteria (original_filename + size_bytes) and that it returns groups of 2+ documents, making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('useful for cleanup after repeated imports'), which implies a specific scenario. However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'list_documents' or 'search_documents' for general document queries), so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange an OAuth authorization code for tokens and store them.
Args: code: The authorization code from the Google OAuth redirect.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core action (exchanging code for tokens and storing them), which implies a write operation with authentication needs. However, it lacks details on error handling, token storage specifics, security implications, or rate limits. The description adds some value but is incomplete for a tool handling sensitive OAuth tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence, followed by a clear parameter explanation. It uses minimal words without redundancy, and every sentence serves a functional role—no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (OAuth token exchange) and the presence of an output schema (which likely covers return values), the description is reasonably complete. It covers the purpose and parameter semantics adequately. However, for a security-sensitive tool, additional context on authentication flows or error cases could enhance completeness, though the output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the 'code' parameter as 'The authorization code from the Google OAuth redirect,' adding semantic meaning beyond the input schema's basic type definition (string). Since schema description coverage is 0%, this compensates well for the single parameter, though it could specify format or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Exchange an OAuth authorization code for tokens and store them.' This is a specific verb ('exchange') + resource ('OAuth authorization code') combination that clearly distinguishes it from sibling tools like 'gdrive_auth_status' or 'gdrive_auth_url', which handle different aspects of authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'authorization code from the Google OAuth redirect,' suggesting it should be used after receiving such a code. However, it does not explicitly state when to use this tool versus alternatives like 'gdrive_auth_url' (which might generate the code) or other auth-related tools, nor does it provide exclusions or prerequisites beyond the code requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the user has valid Google Drive OAuth tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but omits critical details: whether it triggers re-authentication, how it handles expired tokens, what the response format is, or any rate limits. For an auth-related tool, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any fluff. Every word contributes directly to understanding the tool's function, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists (which should detail the response), the description covers the basic purpose adequately. However, for an authentication tool with no annotations, it lacks behavioral context like error handling or token refresh implications, leaving room for improvement despite the structured data support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema coverage is 100% (since there are no parameters to document). The description correctly indicates no parameters are needed, aligning with the schema. A baseline of 4 is appropriate as there's no parameter information to add beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check') and resource ('Google Drive OAuth tokens'), with the qualifier 'valid' distinguishing it from a simple token existence check. It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'gdrive_auth_url' or 'gdrive_sync_status', nor does it mention prerequisites such as needing prior OAuth setup. It lacks any context about typical use cases or integration points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Google OAuth authorization URL for the user to visit.
Returns a URL that the user should open in their browser to authorize Google Drive access. After authorization, Google redirects to the callback URL which stores the tokens automatically.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool returns a URL for user interaction and describes the subsequent flow (Google redirects to callback URL, tokens stored automatically), which adds useful context about the OAuth process. However, it doesn't mention potential errors, rate limits, or authentication requirements beyond the basic flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by essential context about the OAuth flow. Both sentences earn their place by explaining what the tool does and what happens next, with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no annotations, but does have an output schema (implied by 'Returns a URL'), the description provides sufficient context for understanding this OAuth initiation tool. It explains the purpose, output, and subsequent flow, though it could potentially mention what happens if the user is already authorized or if there are scoping considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it focuses instead on the tool's purpose and behavior, which is correct for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the Google OAuth authorization URL') and the resource ('for the user to visit'), distinguishing it from sibling tools like gdrive_auth_callback and gdrive_auth_status. It precisely explains what the tool produces and its purpose in the OAuth flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: as part of the Google Drive authorization process, where the user needs to visit a URL to grant access. It implicitly distinguishes it from other auth-related tools by focusing on URL generation, though it doesn't explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grant writer access to all files/folders in the sync root (one-off fix).
Use this after initial sync when files were created by the service account and are invisible to the folder owner. Also updates the stored owner_email for automatic sharing on future uploads.
Args: email: Email to grant access to. If omitted, detects from folder owner.
| Name | Required | Description | Default |
|---|---|---|---|
| No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: granting writer access to all files/folders, updating owner_email for future sharing, and optional email detection. However, it lacks details on error handling, rate limits, or authentication requirements, which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context and parameter details in a clear 'Args:' section. Every sentence adds value without redundancy, making it efficient and well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with side effects), no annotations, and an output schema (which handles return values), the description is largely complete. It covers purpose, usage, and parameters well, but could benefit from mentioning potential side effects or prerequisites, such as required permissions or idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, but the description fully compensates by explaining the 'email' parameter's purpose ('Email to grant access to'), optional nature ('If omitted'), and fallback behavior ('detects from folder owner'). This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Grant writer access', 'updates') and resources ('all files/folders in the sync root', 'stored owner_email'). It distinguishes itself from siblings by addressing a specific post-sync permission issue, unlike general sync or auth tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('after initial sync when files were created by the service account and are invisible to the folder owner') and its purpose as a 'one-off fix'. It implicitly distinguishes from ongoing sync operations by framing it as a corrective action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the Google Drive folder to sync with.
Detects the folder owner's email and stores it for automatic permission sharing. When the service account creates files/folders, it grants writer access to the original folder owner so they can see the files.
Args: folder_id: The Google Drive folder ID to use as the sync root.
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool detects and stores the folder owner's email for automatic permission sharing and grants writer access when creating files/folders, which adds useful context about permissions and side effects. However, it doesn't cover error handling, rate limits, or response format, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by behavioral details and parameter explanation. Each sentence adds value without redundancy. It could be slightly more front-loaded by moving the parameter info earlier, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves permissions and syncing), no annotations, and an output schema (which reduces need to describe returns), the description is moderately complete. It covers the main action and permissions behavior but lacks details on errors, prerequisites, or integration with sibling tools. This makes it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the single parameter 'folder_id' as 'The Google Drive folder ID to use as the sync root.' This adds meaningful semantics beyond the schema, which has 0% description coverage. Since there's only one parameter and the description fully documents it, the score is high, though not perfect due to lack of format examples (e.g., ID structure).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the Google Drive folder to sync with.' It specifies the verb ('Set') and resource ('Google Drive folder'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'gdrive_sync' or 'setup_gdrive', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare it to similar tools like 'gdrive_sync', or specify scenarios where it's appropriate. This leaves the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run full bidirectional Google Drive sync (runs in background).
Returns immediately with status. Use gdrive_sync_status to check progress and get the result when done.
Imports new/changed files from GDrive (GDrive wins on conflicts)
Exports documents to organized category/year-month folders
Exports manifest + metadata markdown files
Args: dry_run: Preview changes without syncing. enhance: Run AI summary/tag generation on new files (default True).
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| enhance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: runs in background, returns immediately with status, imports/exports files with conflict resolution (GDrive wins), exports organized folders and metadata, and includes AI enhancement options. It lacks details on permissions, rate limits, or error handling, but covers most operational aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the core purpose, followed by usage notes and a numbered list of actions. Every sentence adds value without redundancy, and the parameter explanations are brief yet informative, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bidirectional sync with AI features), no annotations, and an output schema present (which reduces need to describe returns), the description is largely complete. It covers purpose, usage, behaviors, and parameters, but could benefit from more on prerequisites (e.g., auth setup) or error scenarios, though the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: 'dry_run' is explained as 'Preview changes without syncing' and 'enhance' as 'Run AI summary/tag generation on new files (default True)'. This clarifies purpose beyond the bare schema, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Run full bidirectional Google Drive sync') and resource ('Google Drive'), distinguishing it from sibling tools like sync_from_gdrive and sync_to_gdrive by specifying bidirectional operation. It also mentions background execution and immediate return, adding operational context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells when to use this tool ('Run full bidirectional Google Drive sync') and when to use an alternative ('Use gdrive_sync_status to check progress and get the result when done'), clearly differentiating from the sibling tool gdrive_sync_status for monitoring purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of the last or current GDrive sync.
Returns whether a sync is currently running, and the result of the last completed sync (if any).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns ('whether a sync is currently running, and the result of the last completed sync'), which is helpful. However, it doesn't cover other behavioral aspects such as error handling, rate limits, or authentication requirements, limiting its transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and return value. Every sentence earns its place, with no wasted words, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for a status-checking tool. However, it could benefit from more behavioral details, such as error cases or usage examples, to achieve full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's functionality. A baseline of 4 is applied since the schema fully handles parameters, and the description adds value by explaining the tool's purpose without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the status of the last or current GDrive sync.' It specifies the verb ('Check') and resource ('GDrive sync status'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'gdrive_sync' or 'sync_from_gdrive', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'last or current GDrive sync,' suggesting it should be used to monitor sync operations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'gdrive_sync' or 'sync_from_gdrive,' and doesn't specify prerequisites or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated activity statistics by tool and status.
Args: session_id: Filter by session. agent_id: Filter by agent. date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| agent_id | No | ||
| date_from | No | ||
| date_to | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects: whether this requires authentication, what format the aggregated statistics return in, whether there are rate limits, or how null filters behave. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear two-part structure: purpose statement followed by parameter documentation. Both sections are front-loaded and efficient. The only minor improvement would be integrating the parameter explanations more seamlessly rather than using 'Args:' formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and the description covers all parameters, the description is reasonably complete for a read operation. However, for a statistics aggregation tool, additional context about what 'aggregated' means (counts, averages, etc.) and the structure of the output would be helpful despite the output schema's existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides explicit parameter documentation in the Args section, listing all 4 parameters with brief explanations. Since schema description coverage is 0% (no descriptions in the schema properties), the description fully compensates by documenting each parameter's purpose and format (e.g., 'YYYY-MM-DD' for dates). This is valuable semantic information beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get aggregated activity statistics by tool and status.' This specifies the verb ('Get'), resource ('aggregated activity statistics'), and grouping dimensions ('by tool and status'). However, it doesn't explicitly differentiate from sibling tools like 'search_activity_log' or 'get_prompt_log_entry', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several related tools in the sibling list (search_activity_log, get_prompt_log_entry, etc.), but the description doesn't indicate when this aggregated statistics view is preferable to raw log searches or other data retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a persistent state value by key.
Returns {value: null} if the key does not exist.
Args: key: State key name. agent_id: Agent identifier (default: oncoteam).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| agent_id | No | oncoteam |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It helpfully states the return behavior for non-existent keys ('Returns {value: null} if the key does not exist'), which is valuable behavioral information. However, it doesn't mention whether this is a read-only operation, what permissions are required, or any rate limits or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It leads with the core purpose, follows with important behavioral information (null return case), then provides parameter explanations. Every sentence earns its place with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (mentioned in context signals), the description doesn't need to explain return values. It covers the core purpose, key behavioral trait (null return), and parameter meanings. For a simple key-value retrieval tool, this is reasonably complete, though it could benefit from mentioning the sibling relationship with 'list_agent_states'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'key: State key name' and 'agent_id: Agent identifier (default: oncoteam).' This adds meaningful semantics beyond the bare schema. The description doesn't elaborate on key naming conventions or agent_id significance, but provides solid basic parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a persistent state value by key.' This is a specific verb ('Get') + resource ('persistent state value') combination. However, it doesn't explicitly differentiate from its sibling 'list_agent_states' which presumably lists multiple states rather than retrieving a specific one by key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'list_agent_states' or explain when to retrieve a single value versus list all values. The only contextual information is the default agent_id value, which doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a stored calendar entry by ID.
Args: calendar_entry_id: The calendar entry ID.
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_entry_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'full details' but doesn't specify what those details include, whether it's a read-only operation, potential error conditions (e.g., invalid ID), or authentication requirements. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a clear purpose statement followed by a brief parameter explanation. Every sentence adds value without redundancy, and it's front-loaded with the main action. No wasted words or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on usage versus siblings and behavioral details, making it incomplete for optimal agent guidance despite the output schema covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema: it clarifies that 'calendar_entry_id' is an ID for a calendar entry. However, with 0% schema description coverage and only one parameter, the baseline is 4, but the description doesn't fully compensate by explaining format constraints (e.g., numeric ID range) or examples, so it scores slightly lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details of a stored calendar entry by ID.' It specifies the verb ('Get'), resource ('calendar entry'), and scope ('by ID'), making the action unambiguous. However, it doesn't differentiate from sibling tools like 'search_calendar_events' or 'get_treatment_event', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_calendar_events' for broader queries or 'get_treatment_event' for similar ID-based retrieval, nor does it specify prerequisites (e.g., needing a valid calendar entry ID). This lack of context leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a single conversation entry by ID.
Args: entry_id: The conversation entry ID.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool retrieves 'full content' but does not cover critical aspects like authentication needs, rate limits, error handling, or data format. For a read operation with no annotation support, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a clear purpose statement followed by a brief parameter explanation. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the core purpose and parameter semantics adequately, though it could improve by addressing behavioral aspects like error cases or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter: 'entry_id: The conversation entry ID.' Since schema description coverage is 0% (the schema only specifies type: integer), this clarifies the parameter's purpose beyond the schema. However, it lacks details on ID format or sourcing, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the full content of a single conversation entry by ID.' It specifies the verb ('Get'), resource ('conversation entry'), and scope ('by ID'). However, it does not explicitly differentiate from sibling tools like 'search_conversations' or 'log_conversation', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., needing a valid entry ID), exclusions, or comparisons to siblings like 'search_conversations' for broader queries. This minimal guidance limits effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a document's metadata and file_id for Claude to analyze.
Returns the file_id that can be used to reference the document in conversation.
Args: file_id: The Anthropic Files API file_id.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool returns metadata and a file_id, and that the file_id can be used for conversation reference. However, it doesn't mention error conditions, permissions needed, rate limits, or whether this is a read-only operation (though 'get' implies reading).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with three focused sentences: purpose statement, return value usage, and parameter clarification. It's front-loaded with the core purpose. The 'Args:' section could be integrated more smoothly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values don't need explanation), a single parameter with good semantic clarification, and no complex behavioral requirements, the description is reasonably complete. It could benefit from more usage guidance relative to siblings, but covers the essentials for this simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter beyond the schema (which has 0% description coverage). It specifies that 'file_id' refers to 'The Anthropic Files API file_id', clarifying the parameter's origin and format. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a document's metadata and file_id for Claude to analyze, specifying both the action (get) and resource (document). It distinguishes from sibling 'get_document_by_id' by not mentioning ID-based retrieval, but doesn't explicitly differentiate from 'view_document' or other document-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a file_id for Claude analysis, but provides no explicit guidance on when to use this versus alternatives like 'get_document_by_id', 'view_document', or 'list_documents'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a document's metadata by its integer database ID.
Use this when you have the numeric document ID (e.g. from search results or lab values).
Args: doc_id: The integer database ID of the document.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't disclose other behavioral traits like authentication needs, rate limits, error conditions, or what 'metadata' specifically includes. The description adds basic context but lacks depth for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and parameter details in a structured 'Args:' section. Every sentence earns its place with no wasted words, making it easy to parse and efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only operation) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, usage, and parameter semantics adequately. A slight gap exists in behavioral details like error handling, but the output schema mitigates this, making it very helpful overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by explaining the single parameter 'doc_id' as 'The integer database ID of the document,' adding meaning beyond the schema's type definition. It clarifies that this is a numeric ID from the database, which is crucial context not in the schema. With only one parameter, this is sufficient for high utility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a document's metadata') and resource ('by its integer database ID'), distinguishing it from sibling tools like 'get_document' (which likely uses a different identifier) and 'view_document' (which might retrieve content rather than metadata). The verb 'Get' is precise and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this when you have the numeric document ID (e.g. from search results or lab values).' This clearly indicates when to use this tool versus alternatives like 'search_documents' or 'list_documents' that don't require a specific ID, making it highly actionable for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get per-document status matrix showing OCR, AI, metadata, sync, and rename state.
Returns a table of documents with their processing status at each pipeline stage. Use filters to find documents that need attention.
Args: filter: Filter documents — 'all', 'missing_ocr', 'missing_ai', 'missing_metadata', 'not_synced', 'not_renamed', 'incomplete' (any gap). limit: Maximum documents to return (max 200).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | all | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format ('table of documents') and processing behavior, but doesn't mention rate limits, authentication requirements, or whether this is a read-only operation. The description adds useful context about what the tool returns but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with three focused sentences: purpose statement, return format explanation, and usage guidance. The parameter documentation is cleanly separated with 'Args:' section. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, but with output schema present, the description is quite complete. It explains purpose, usage, parameters, and return format. The main gap is lack of behavioral details like authentication or rate limits, but the output schema reduces need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters in detail. It provides the complete enum values for 'filter' parameter and clarifies the meaning and constraints of 'limit' (max 200). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Get') and resource ('per-document status matrix'), detailing what processing stages are included (OCR, AI, metadata, sync, rename). It distinguishes from sibling tools like 'get_pipeline_status' by focusing on document-level status rather than overall pipeline health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to find documents that need attention') and implies usage through filter options like 'missing_ocr', but doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history chain for a document.
Returns all versions (current and previous) ordered newest first. Works with any document ID in the chain — will find the full history.
Args: doc_id: The integer database ID of any document in the version chain.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return behavior ('Returns all versions ordered newest first') and clarifies that it works with any document ID in the chain. However, it lacks details about permissions, rate limits, error conditions, or whether this is a read-only operation (though 'Get' implies safety).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a purpose statement, behavioral details, and parameter explanation in three concise sentences. Every sentence adds value, and information is front-loaded with the core purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read-like operation), no annotations, but with an output schema present, the description is mostly complete. It explains what the tool does, how to use it, and the parameter semantics. The output schema will handle return value details, so the description appropriately focuses on behavior and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides a clear explanation of the single parameter ('doc_id: The integer database ID of any document in the version chain'), including its data type (integer) and semantic meaning (any document in the chain). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('version history chain for a document'), and distinguishes it from siblings like 'get_document' or 'get_document_by_id' by focusing on version history rather than document content. The phrase 'ordered newest first' adds specificity about the output ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Get the version history chain for a document') and implicitly distinguishes it from document retrieval tools. However, it does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a stored email entry by ID.
Args: email_entry_id: The email entry ID.
| Name | Required | Description | Default |
|---|---|---|---|
| email_entry_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't clarify permissions, rate limits, error handling, or what 'full details' includes. For a tool with zero annotation coverage, this is insufficient to guide safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement followed by a brief 'Args' section. It avoids redundancy and wastes no words, though the 'Args' formatting is slightly informal for MCP standards. Every sentence earns its place, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter) and the presence of an output schema (which handles return values), the description is moderately complete. However, with no annotations and minimal behavioral or usage context, it leaves gaps in guiding the agent effectively. It's adequate but could be more informative for a read operation in a clinical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema: it names the parameter ('email_entry_id') and specifies it's 'The email entry ID.' With 0% schema description coverage, this provides some context, but it doesn't explain format, constraints, or examples. The baseline is 3 since the schema covers the parameter's existence and type, but the description doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details of a stored email entry by ID.' It specifies the verb ('Get'), resource ('stored email entry'), and scope ('full details by ID'). However, it doesn't differentiate from sibling tools like 'search_emails' or 'get_document_by_id', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_emails' for broader queries or 'get_document' for other document types, nor does it specify prerequisites or exclusions. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a unified chronological timeline merging documents and conversation entries.
This is the complete view of the oncology journey — documents and diary entries interleaved by date. Useful for book writing, doctor sharing, or reviewing history.
Args: date_from: Start date (YYYY-MM-DD). date_to: End date (YYYY-MM-DD). limit: Maximum items per type (default 200).
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | No | ||
| date_to | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a read operation ('Get'), implies no destructive actions, and mentions the scope ('complete view of the oncology journey'), but lacks details on permissions, rate limits, or error handling. It adds some context but is not comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement upfront, usage context in the second paragraph, and parameter details in a formatted 'Args' section. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is mostly complete: it covers purpose, usage, and parameter semantics. The output schema likely handles return values, so the description doesn't need to explain them. However, it could improve by addressing behavioral aspects like permissions or limitations more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'date_from' and 'date_to' are explained as start and end dates with format (YYYY-MM-DD), and 'limit' is described as 'Maximum items per type' with a default. This effectively clarifies parameter purposes beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get a unified chronological timeline') and resources ('merging documents and conversation entries'), distinguishing it from siblings like 'get_conversation' or 'get_document' by emphasizing the merged, chronological nature. It explicitly mentions the oncology journey context, making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage contexts ('Useful for book writing, doctor sharing, or reviewing history'), which helps an agent understand when to apply this tool. However, it does not explicitly state when not to use it or name alternative tools (e.g., 'get_conversation' or 'get_document' for separate views), missing full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lab safety check against thresholds appropriate for the patient type.
For oncology patients: mFOLFOX6 pre-cycle thresholds (NCCN + SmPC). For general patients: standard health reference ranges (EU/WHO/ESC).
For each safety parameter, returns:
The threshold (min or max) with source/guideline reference
The patient's most recent value with date and source document
Safety status: green (safe), red (unsafe), yellow (borderline ±10%)
Clickable gdrive_url to verify the source lab document
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by detailing behavioral aspects: it specifies threshold sources (NCCN, SmPC, EU/WHO/ESC), returns safety status with color codes, includes clickable verification links, and describes the output structure. However, it omits details like error handling, performance, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by patient-type specifics and output details. Every sentence adds value, but it could be slightly more concise by combining some clauses without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (safety checking with multiple guidelines), no annotations, and an output schema present, the description is complete. It covers purpose, patient-type logic, threshold sources, return values, and verification links, providing all necessary context without needing to explain output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's function and output without redundant parameter details, earning a baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'lab safety check against thresholds appropriate for the patient type,' specifying distinct threshold sets for oncology vs. general patients. It differentiates from siblings like 'analyze_labs' or 'get_lab_summary' by focusing on safety status against guidelines rather than analysis or summary reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for safety checking based on patient type (oncology or general) but does not explicitly state when to use this tool versus alternatives like 'compare_lab_panels' or 'get_lab_trends.' It provides context on patient types but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of the latest value for every tracked lab parameter.
Returns status (normal/high/low), trend direction (rising/falling/stable), days since last measurement, and computed indices (SII, Ne/Ly ratio). Designed as a quick overview for clinical decision support.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return values (status, trend direction, etc.) and the tool's design intent, which adds useful context. However, it lacks details on potential limitations, such as data freshness, error handling, or performance characteristics, which would be beneficial for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by details on returns and design intent in subsequent sentences. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, an output schema exists, and no annotations, the description is largely complete—it explains the purpose, returns, and usage context. However, it could be more comprehensive by addressing potential behavioral aspects like data sources or update frequency, though the output schema may cover return values, reducing the need for such details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. It adds value by explaining the output semantics (e.g., 'status', 'trend direction'), compensating for the lack of parameter info, though this is more about output than input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get a summary') and resources ('latest value for every tracked lab parameter'), and distinguishes it from siblings like 'get_lab_time_series' or 'get_lab_trends' by focusing on a comprehensive overview rather than detailed analysis. It explicitly mentions what it returns (status, trend direction, etc.), making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Designed as a quick overview for clinical decision support'), indicating when to use this tool—for a rapid summary rather than in-depth analysis. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as 'analyze_labs' or 'compare_labs', which could enhance differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get structured time series data for one or more lab parameters.
Returns chronological values with reference ranges, units, and computed deltas (absolute change and % change between consecutive measurements). Designed for Oncoteam and MCP clients to build trend charts and analysis.
Args: parameters: Comma-separated parameter names (e.g. "CEA,CA19_9" or "PLT"). date_from: Start date filter (YYYY-MM-DD). Optional. date_to: End date filter (YYYY-MM-DD). Optional.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | ||
| date_from | No | ||
| date_to | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns chronological values with reference ranges, units, and computed deltas, which adds behavioral context beyond basic retrieval. However, it lacks details on permissions, rate limits, or error handling that would be important for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose, followed by return details, usage context, and parameter explanations in a bullet-like format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is fairly complete. It explains the purpose, return data structure, and parameter usage, though it could benefit from more behavioral details like data source or limitations, which the output schema might cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'parameters' are comma-separated names with examples (e.g., 'CEA,CA19_9'), and clarifies that date filters are optional with format 'YYYY-MM-DD', which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get structured time series data') and resources ('lab parameters'), distinguishing it from siblings like get_lab_summary or get_lab_trends by focusing on chronological values with computed deltas for trend analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for building trend charts and analysis, targeting Oncoteam and MCP clients, but does not explicitly state when to use this tool versus alternatives like get_lab_summary or get_lab_trends, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stored lab values for trend analysis.
Returns values sorted chronologically (oldest first) for plotting trends.
Args: parameter: Filter by parameter name (e.g. PLT, SII, CEA). If None, returns all. date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| parameter | No | ||
| date_from | No | ||
| date_to | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that results are 'sorted chronologically (oldest first) for plotting trends,' which is useful behavioral context. However, it doesn't mention permissions, rate limits, error handling, or what happens with missing data—significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the purpose, follows with behavioral context, and lists parameters clearly. Every sentence adds value, though the parameter explanations could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameter semantics and sorting behavior. Since an output schema exists, it doesn't need to detail return values. However, it lacks error handling or permission context, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all 4 parameters: explaining that 'parameter' filters by name (e.g., 'PLT, SII, CEA'), 'date_from' and 'date_to' filter by date range in YYYY-MM-DD format, and 'limit' sets maximum results. This goes beyond the schema's basic types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve stored lab values for trend analysis.' It specifies the verb ('retrieve'), resource ('stored lab values'), and context ('for trend analysis'). However, it doesn't explicitly differentiate from sibling tools like 'get_lab_summary' or 'get_lab_time_series', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_lab_summary' or 'get_lab_time_series', nor does it specify prerequisites or exclusions. Usage is implied through parameter descriptions but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current patient clinical context.
Returns structured patient data including diagnosis, biomarkers, treatment, metastases, comorbidities, and excluded therapies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns structured patient data but doesn't clarify whether this is a read-only operation, if it requires authentication, what happens if no patient is selected, or any rate limits. While it implies a safe read operation, critical behavioral traits are missing for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose, and the second details the returned data. Every sentence adds value without redundancy, and it's front-loaded with the core function. There's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving clinical context), the description is moderately complete. It specifies the returned data types, which is helpful, and an output schema exists to detail the return values. However, with no annotations and missing behavioral context (e.g., prerequisites, error conditions), it leaves gaps that could hinder an agent's correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline of 4 is appropriate as the description compensates by explaining what data is returned (diagnosis, biomarkers, etc.), which is valuable context for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current patient clinical context' with a specific verb ('Get') and resource ('patient clinical context'). It distinguishes itself from siblings like 'update_patient_context' (which modifies rather than retrieves) and 'select_patient' (which likely chooses a patient rather than fetching their data). However, it doesn't explicitly differentiate from other data-fetching tools like 'get_document' or 'get_lab_summary', which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a patient must be selected first), exclusions, or comparisons to similar tools like 'get_journey_timeline' or 'get_lab_summary'. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pipeline operations status: scheduled jobs, stage counts, and sync history.
Shows which automated processes run, their schedule, last results, and how many documents are at each pipeline stage (OCR → AI → metadata → sync → rename).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what information the tool returns (scheduled jobs, stage counts, sync history, process schedules, last results, document stage breakdowns). However, it doesn't mention performance characteristics, data freshness, authentication requirements, or error conditions that would be important for a monitoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two sentences that pack substantial information. The first sentence establishes the core function, while the second elaborates with specific examples. There's no wasted verbiage, though it could be slightly more front-loaded by moving the pipeline stage details to a separate sentence for better scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, an output schema exists, and no annotations, the description provides good coverage of what the tool returns. It explains the types of status information available and breaks down the pipeline stages. However, it doesn't mention the format or structure of the returned data, which the output schema presumably covers, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters and focuses instead on what the tool returns, which is correct for a parameter-less status query tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Shows') and resources ('pipeline operations status', 'automated processes', 'documents at each pipeline stage'). It distinguishes itself from siblings by focusing on pipeline monitoring rather than document manipulation, authentication, or data analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is provided. While the description implies usage for monitoring pipeline operations, it doesn't specify prerequisites, timing considerations, or contrast with related tools like 'gdrive_sync_status' or 'system_health' that might provide overlapping information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full pre-cycle checklist for mFOLFOX6 with source references.
Returns all checklist sections (lab safety, toxicity, VTE, general) with guideline source URLs for each item. Lab items include the patient's latest value and safety status.
Args: cycle_number: Current cycle number (for display context).
| Name | Required | Description | Default |
|---|---|---|---|
| cycle_number | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (all checklist sections with source URLs, lab items with latest values and safety status) and mentions the display context purpose of the cycle_number parameter. It doesn't cover potential limitations like authentication requirements, rate limits, or error conditions, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three focused sentences: purpose statement, return value details, and parameter explanation. Each sentence adds essential information without redundancy. The information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (medical checklist retrieval), no annotations, and the presence of an output schema, the description provides good coverage. It explains what data is returned and why the parameter matters. The output schema presumably handles return value details, so the description appropriately focuses on operational context rather than output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter beyond what the schema provides (0% coverage). It explains that cycle_number is 'for display context' rather than just being a numeric input. This clarifies the parameter's purpose and how it affects the output, compensating well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get the full pre-cycle checklist') and resources ('for mFOLFOX6 with source references'). It distinguishes itself from siblings by specifying the exact checklist type (mFOLFOX6) and content (lab safety, toxicity, VTE, general sections with source URLs and patient data). No sibling tools appear to provide similar checklist functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve a specific chemotherapy regimen checklist with references and patient data). However, it doesn't explicitly state when NOT to use it or name alternative tools for similar purposes. The context is sufficient but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get EU preventive care screening compliance for a general health patient.
Evaluates which screenings (colonoscopy, dental, ophthalmology, PSA, etc.) are up-to-date, due soon, overdue, or never done — based on patient age, sex, and treatment_events history.
Only available for patients with patient_type="general" in their context. Requires date_of_birth and sex in patient context.
Returns a compliance report with actionable screening status for each applicable protocol.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes what the tool evaluates (screenings like colonoscopy, dental, etc.), the basis for evaluation (patient age, sex, treatment_events history), and the return format (compliance report with actionable screening status). It doesn't mention rate limits or authentication needs, but covers the core functionality adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three paragraphs: purpose, evaluation criteria/constraints, and return value. Every sentence adds essential information without redundancy, and it's front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description provides complete context. It explains what the tool does, when to use it, what it requires, what it evaluates, and what it returns - covering all necessary aspects without needing to duplicate structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on context requirements (patient_type, date_of_birth, sex) rather than input parameters, adding value by clarifying what data must be available in the patient context for the tool to function correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'Evaluates') and resources ('EU preventive care screening compliance', 'general health patient'). It distinguishes itself from siblings by focusing on preventive care status assessment rather than document management, lab analysis, or other patient operations listed among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Only available for patients with patient_type="general" in their context') and prerequisites ('Requires date_of_birth and sex in patient context'). It provides clear context for application without needing to reference specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single prompt log entry with full prompts and raw response.
Returns the complete AI call record including system prompt, user prompt, raw AI response, token counts, and timing. Use search_prompt_log to find entries.
Args: entry_id: The prompt log entry ID.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return content ('complete AI call record including system prompt, user prompt, raw AI response, token counts, and timing'), which adds useful context beyond basic functionality. However, it lacks details on error handling, permissions, or rate limits, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by details on returns and usage guidelines, with zero wasted words. Each sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter), the presence of an output schema (which handles return values), and the description's coverage of purpose, usage, and parameter semantics, it is complete enough for effective use. The description addresses key aspects without overloading, fitting the context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the description compensates by explaining 'entry_id: The prompt log entry ID,' adding semantic meaning that clarifies it's an identifier for retrieval. Since there's only one parameter and the description covers it adequately, this meets the baseline for low parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a single prompt log entry') and resource ('full prompts and raw response'), distinguishing it from the sibling tool 'search_prompt_log' which is for finding entries rather than retrieving a specific one. The verb 'Get' combined with the detailed scope makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by stating 'Use search_prompt_log to find entries,' which clarifies when to use this tool (to retrieve a specific entry by ID) versus the alternative (to search for entries). This direct naming of the sibling tool and its purpose offers clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a treatment event by ID.
Args: event_id: The treatment event ID.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover other critical aspects: authentication requirements, error handling (e.g., what happens if the ID is invalid), rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and front-loaded: the first sentence states the core purpose, followed by a brief 'Args' section. There's no wasted text. However, the structure could be slightly improved by integrating the parameter explanation into the main description rather than a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally complete. It covers the basic purpose and parameter, but lacks context on usage, behavioral details, and error handling. With no annotations and simple inputs, it meets the baseline but doesn't provide rich guidance for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description adds basic semantics: it explains that 'event_id' is 'The treatment event ID' and that it's required to get details. However, it doesn't specify format constraints (e.g., integer range), source of IDs, or examples. With one parameter and low schema coverage, this provides minimal but adequate clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details of a treatment event by ID.' It specifies the verb ('Get') and resource ('treatment event'), and distinguishes it from siblings like 'list_treatment_events' (which lists events) and 'update_treatment_event' (which modifies events). However, it doesn't explicitly differentiate from 'get_document_by_id' or 'get_calendar_event', which are similar 'get by ID' operations for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list_treatment_events' for browsing events or 'update_treatment_event' for modifying them. There's also no context about prerequisites (e.g., needing an event ID from elsewhere) or exclusions (e.g., not for creating events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start Gmail authorization flow. Returns a URL the user must visit.
After visiting the URL and completing Google's consent screen, Gmail read access will be enabled. Call integration_status() to verify.
WARNING: This grants read access to ALL emails in the Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses critical behavioral traits: the tool returns a URL, requires user interaction with Google's consent screen, enables read access to ALL emails (not just some), and has a verification step. The WARNING about scope of access is particularly valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each earn their place: states the purpose, describes the return value and required user action, provides next-step guidance, and includes a critical warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authorization tool with no annotations, 0 parameters, and an output schema (which handles return values), the description provides complete context. It covers purpose, workflow, security implications, and integration with other tools, leaving no significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, focusing instead on the tool's behavioral semantics and workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start Gmail authorization flow') and the resource involved ('Gmail read access'). It distinguishes itself from sibling tools like 'calendar_auth_enable' by specifying Gmail, and from 'integration_status' by initiating rather than verifying authorization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Start Gmail authorization flow') and what to do after ('Call integration_status() to verify'). It also distinguishes from alternatives by specifying this is for Gmail (not other services like calendar or gdrive).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which Google services are connected and entry counts.
Returns the status of Drive, Gmail, and Calendar integrations, including whether each is authorized and how many entries are stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it indicates this is a read operation (showing/returning status), it doesn't mention authentication requirements, rate limits, whether it's a real-time check or cached data, what happens if services aren't configured, or error conditions. For a status-checking tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured. The first sentence immediately states the core purpose, and the second sentence provides valuable clarifying detail about which specific services are covered. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has zero parameters, 100% schema coverage, and an output schema exists, the description provides adequate basic context. However, as a status-checking tool with no annotations, it should ideally mention authentication requirements or what 'authorized' means in practice. The existence of an output schema reduces the need to describe return values, but behavioral aspects remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description correctly indicates no parameters are needed ('Show which Google services are connected' implies a parameterless status check), which aligns perfectly with the empty input schema. No additional parameter semantics are needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show which Google services are connected and entry counts' and 'Returns the status of Drive, Gmail, and Calendar integrations'. It specifies the verb ('show', 'returns') and resources (Drive, Gmail, Calendar integrations), but doesn't explicitly differentiate from sibling tools like 'gdrive_auth_status' or 'system_health' that might provide overlapping status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites exist, or how it differs from similar sibling tools like 'gdrive_auth_status', 'gdrive_sync_status', or 'system_health'. The agent receives no usage context beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all persistent state keys for an agent.
Args: agent_id: Agent identifier (default: oncoteam). limit: Maximum number of states to return (default 100, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | oncoteam | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read-only listing operation but lacks details on permissions, rate limits, pagination, error handling, or the format of returned data. The mention of 'persistent state keys' hints at storage behavior, but this is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by parameter details in a structured 'Args:' section. It is appropriately sized with no redundant information, though the parameter explanations could be slightly more detailed given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which reduces the need to describe return values), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it lacks behavioral context and usage guidelines, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining both parameters: 'agent_id' as 'Agent identifier (default: oncoteam)' and 'limit' as 'Maximum number of states to return (default 100, max 500).' This adds crucial semantic context beyond the schema's type and default values, though it does not fully cover all potential constraints or usage nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all persistent state keys for an agent.' This specifies the verb ('List'), resource ('persistent state keys'), and scope ('for an agent'). However, it does not explicitly differentiate from its sibling tool 'get_agent_state', which appears to retrieve a specific state rather than list keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_agent_state' or 'set_agent_state', nor does it specify prerequisites, contexts, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored medical documents with metadata.
Returns documents ordered by date (newest first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: it describes the return order ('ordered by date, newest first') and implies a read-only operation (listing). However, it lacks details on permissions, rate limits, pagination behavior (beyond limit/offset in schema), or error handling, which are important for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first states the purpose, and the second adds behavioral context (ordering). There is no wasted language, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation), no annotations, and the presence of an output schema, the description is minimally adequate. It covers the basic purpose and ordering but lacks details on usage guidelines, parameter explanations, and behavioral traits like pagination or error handling, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention the 'limit' and 'offset' parameters at all, failing to explain their purpose (e.g., pagination). However, since there are only 2 parameters and an output schema exists, the baseline is 3, as the description does not add meaningful parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all stored medical documents with metadata.' It specifies the verb ('List'), resource ('medical documents'), and scope ('all stored'), but does not explicitly differentiate it from sibling tools like 'search_documents' or 'get_document_by_id', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'search_documents' (for filtered searches) or 'get_document_by_id' (for specific documents), nor does it specify prerequisites or exclusions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available patients.
Shows active patients with their slug, name, document count, and patient type. Use select_patient to switch to a different patient.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it shows 'active patients' and specifies the fields returned (slug, name, document count, patient type), which is valuable behavioral information. However, it doesn't mention pagination, sorting, filtering capabilities, or any rate limits/authentication requirements that might be relevant for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured: two sentences that each serve a clear purpose. The first sentence states the core functionality, the second provides crucial usage guidance. There is zero wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a read-only list operation with 0 parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It explains what the tool does, what information it returns, and when to use it versus the key sibling tool. The main gap is lack of behavioral details like pagination or filtering limitations, but for a simple list tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline would be 3. However, the description adds value by clarifying that this lists 'all available patients' and 'active patients,' which helps the agent understand this is a parameterless operation that returns a complete set rather than requiring filtering parameters. This semantic clarification justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all available patients' with specific details about what information is shown (slug, name, document count, patient type). It distinguishes from the sibling 'select_patient' by mentioning it's for switching patients, not listing them. However, it doesn't explicitly differentiate from other list/search tools like 'list_documents' or 'search_documents'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: 'Use select_patient to switch to a different patient.' This clearly distinguishes between listing patients and selecting/activating a patient. It also implies this is for viewing active patients only, though it doesn't explicitly exclude inactive ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved research entries, optionally filtered by source.
Args: source: Filter by source (e.g. pubmed, clinicaltrials). limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions optional filtering and a limit parameter but doesn't disclose whether this is a read-only operation, how results are ordered, if pagination is supported, or what the output format looks like. For a list tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, though the Args section could be integrated more smoothly. It avoids redundancy and stays focused on essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema, the description covers basic purpose and parameters adequately. However, with no annotations and 0% schema description coverage, it should provide more behavioral context (e.g., read-only nature, result ordering) to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: 'source' filters by specific sources with examples, and 'limit' sets maximum results. However, it doesn't clarify default behaviors (limit defaults to 50 per schema), source validation, or what happens with invalid inputs. The description adds basic meaning but leaves operational details unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('saved research entries'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'search_research' by focusing on listing rather than searching, though it doesn't explicitly contrast with 'add_research_entry' or other research-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_research' or 'get_document_by_id' for research entries. The description mentions optional filtering by source but doesn't explain when this filtering is appropriate or what happens without it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered MCP tools with their descriptions and parameter schemas.
Returns the complete tool inventory for discovery and documentation. Useful for agents to understand available capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool returns ('complete tool inventory') but doesn't describe format, pagination, or performance characteristics. The description doesn't contradict any annotations (none exist), but provides only basic behavioral information without details about response structure or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: first states the core functionality, second explains the return value, third provides usage context. No wasted words, front-loaded with the essential information, and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read-only tool with 0 parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It explains what the tool does and why to use it. However, with no annotations and being a meta-tool for system discovery, it could benefit from mentioning whether it requires special permissions or has any rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't discuss parameters since none exist. It focuses instead on what the tool returns, which is appropriate for a parameterless tool. Baseline would be 4 for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all registered MCP tools with their descriptions and parameter schemas.' This specifies the verb ('List'), resource ('registered MCP tools'), and scope ('all'). However, it doesn't explicitly differentiate from sibling tools like 'list_documents' or 'list_patients' beyond implying this is a meta-tool for tool discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'for discovery and documentation' and 'Useful for agents to understand available capabilities.' This gives explicit guidance on its primary use cases. However, it doesn't mention when NOT to use it or suggest alternatives for specific tool discovery needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List soft-deleted documents in trash.
Args: limit: Maximum results to return (default 50, max 200).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only minimally describes behavior. It mentions 'soft-deleted documents' but doesn't clarify authentication requirements, rate limits, pagination, or what 'soft-deleted' entails (e.g., retention period, recoverability). The description is insufficient for a mutation-sensitive context like trash management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. Every sentence adds value with no wasted words, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an output schema (which handles return values), the description is minimally adequate. However, given the sensitive nature of trash operations and lack of annotations, it should ideally mention permissions, data sensitivity, or relationship to restore/delete tools for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'limit' by specifying default (50) and maximum (200) values, which aren't in the schema (0% coverage). This compensates well for the schema's lack of descriptions, though it doesn't explain sorting, filtering, or other implicit behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List soft-deleted documents') and resource ('in trash'), distinguishing it from siblings like list_documents, delete_document, and restore_document. It precisely communicates this tool retrieves only soft-deleted items rather than active documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_documents, restore_document, or delete_document. The description lacks context about prerequisites, permissions needed, or typical workflows involving trash management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List treatment events, optionally filtered by type and date range.
Returns events in reverse chronological order.
Args: event_type: Filter by event type (e.g. chemo, surgery). date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| event_type | No | ||
| date_from | No | ||
| date_to | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: events are returned in 'reverse chronological order', and it mentions filtering capabilities and a limit parameter. However, it doesn't cover critical aspects like pagination, error handling, authentication needs, or rate limits, which are important for a list operation with potential large datasets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the core purpose, the second adds behavioral context (ordering), and the Args section efficiently details parameters. Every sentence earns its place with no wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, list operation) and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, ordering, and parameter meanings. However, without annotations, it could benefit from more behavioral details (e.g., pagination, auth), but the output schema reduces the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 4 parameters: 'event_type' (e.g., chemo, surgery), 'date_from' and 'date_to' (YYYY-MM-DD format), and 'limit' (maximum results). This adds significant value beyond the bare schema, though it doesn't specify default values or constraints like the 50 default for limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List treatment events, optionally filtered by type and date range.' This specifies the verb ('List') and resource ('treatment events'), and distinguishes it from sibling tools like 'get_treatment_event' (singular) or 'add_treatment_event'. However, it doesn't explicitly differentiate from other list tools (e.g., 'list_patients', 'list_documents'), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'optionally filtered by type and date range', suggesting when to apply filters. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_activity_log' or 'get_journey_timeline', which might overlap in functionality. No exclusions or prerequisites are mentioned, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a diary entry to the conversation archive.
Use this to log summaries, decisions, progress notes, questions, or any narrative content from conversations about the oncology journey.
Args: title: Short title for the entry. content: Markdown body with the full entry text. entry_date: Date the entry is about (YYYY-MM-DD). Defaults to today. entry_type: Type of entry: summary, decision, progress, question, note. tags: Comma-separated tags (e.g. "chemo,FOLFOX,cycle-3"). document_ids: Comma-separated document IDs referenced (e.g. "3,15"). participant: Who created this: claude.ai, claude-code, oncoteam.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| entry_date | No | ||
| entry_type | No | note | |
| tags | No | ||
| document_ids | No | ||
| participant | No | claude.ai |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a write operation ('Save'), but doesn't mention permissions, whether entries are editable/deletable, or any rate limits. The description adds useful context about the oncology journey domain, but lacks important behavioral details for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by usage guidance and detailed parameter explanations. Every sentence adds value, though the parameter section is somewhat lengthy. It's appropriately sized for a tool with 7 parameters and good front-loading of the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation) and the presence of an output schema (which means return values don't need explanation), the description is quite complete. It covers purpose, usage context, and detailed parameter semantics. The main gap is lack of behavioral details like permissions or mutation consequences, but with an output schema, this is less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters, the description provides excellent parameter semantics. It clearly explains each parameter's purpose, format, and defaults where applicable (e.g., 'Defaults to today' for entry_date, 'Comma-separated tags' for tags, 'Type of entry: summary, decision, progress, question, note' for entry_type). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Save') and resource ('diary entry to the conversation archive'), and distinguishes it from siblings by specifying it's for logging narrative content about the oncology journey. It provides concrete examples of what to log (summaries, decisions, progress notes, questions), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to log summaries, decisions, progress notes, questions, or any narrative content from conversations about the oncology journey'), which helps distinguish it from sibling tools like add_activity_log or add_research_entry. However, it doesn't explicitly state when NOT to use it or name specific alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze activity logs for errors, slow tools, and improvement opportunities.
Scans the audit trail for patterns: recurring errors, slow operations, failed storage, and usage trends. Returns actionable findings that can be used to create GitHub improvement issues.
Args: days: Number of days to analyze (default 7).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions scanning logs and returning findings, but doesn't specify whether this is a read-only operation, its performance impact, rate limits, or authentication requirements. For a tool that analyzes logs (potentially large datasets), this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by details on scanning patterns and return value. It uses two concise paragraphs and a clear 'Args' section, with no wasted sentences. Minor improvement could be integrating the parameter info more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing logs for patterns), the description covers purpose, parameter semantics, and output intent (actionable findings for GitHub issues). With an output schema present, it doesn't need to detail return values. However, without annotations, it could better address behavioral aspects like data access scope or performance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'days' by explaining it as 'Number of days to analyze (default 7),' which clarifies its purpose beyond the schema's basic type and default. With 0% schema description coverage, this compensates well, though it could note constraints like minimum/maximum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing activity logs for errors, slow tools, and improvement opportunities. It specifies the resource (activity logs) and the analysis scope (patterns like recurring errors, slow operations, etc.). However, it doesn't explicitly differentiate from sibling tools like 'search_activity_log' or 'get_activity_stats', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning it 'scans the audit trail for patterns' and returns 'actionable findings for GitHub improvement issues,' suggesting it's for diagnostic or optimization purposes. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_activity_log' or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only SQL query against the production database.
Use this for monitoring, debugging, and ad-hoc analysis. Only SELECT/WITH queries are allowed — mutations are blocked.
Args: sql: SQL query (SELECT only). Tables: documents, activity_log, conversations, treatment_events, research_entries, lab_values, document_pages, agent_state, patient_context, schema_migrations. limit: Max rows to return (default 50, max 200).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it specifies the tool is 'read-only,' blocks mutations, lists available tables, and includes rate-limiting details (default 50, max 200 rows). However, it does not mention authentication needs, error handling, or performance implications, leaving some gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by usage guidelines and detailed parameter explanations. Every sentence adds value, such as clarifying allowed query types and table availability, with no redundant or wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only SQL queries), lack of annotations, and presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage, behavioral constraints, and parameter details, providing all necessary context for an AI agent to select and invoke the tool correctly without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains the 'sql' parameter as 'SQL query (SELECT only)' and lists the available tables, and specifies the 'limit' parameter's default and maximum values. This fully compensates for the lack of schema descriptions, providing clear semantics for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Run') and resource ('SQL query against the production database'), and distinguishes it from siblings by emphasizing read-only operations. It explicitly mentions 'Only SELECT/WITH queries are allowed — mutations are blocked,' which differentiates it from tools like add_activity_log or delete_document that perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating 'Use this for monitoring, debugging, and ad-hoc analysis' and 'Only SELECT/WITH queries are allowed — mutations are blocked.' This clearly indicates when to use this tool (for read-only queries) versus when not to (for mutations), with alternatives implied in sibling tools like add_activity_log or update_treatment_event for write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and fix GDrive folder structure issues.
Scans for: unknown folders, root-level files not in any category folder, empty managed folders, and stale backup folders.
Args: dry_run: If True (default), report issues without making changes. If False, move files, rename folders, and clean up backups.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: scanning for specific issues and, based on the 'dry_run' parameter, either reporting issues or making changes (moving files, renaming folders, cleaning up backups). It clarifies the default behavior (dry_run=True) and the impact of setting it to False, which is crucial for a mutation tool. However, it does not mention potential side effects, permissions required, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by specific scanning targets and parameter details. Every sentence earns its place by providing essential information without redundancy. The structure is logical, with a brief overview and then focused details on arguments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation tool with behavioral dependencies on a parameter) and the presence of an output schema (which likely covers return values), the description is mostly complete. It covers purpose, usage context, parameter semantics, and behavioral traits. However, without annotations, it could benefit from mentioning permissions or potential risks, but the output schema reduces the need to explain return values, making it adequate for most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and only one parameter ('dry_run') with no schema description. The description compensates fully by explaining the parameter's semantics: it defines what 'dry_run' does (report issues without changes if True, make changes if False), specifies the default value (True), and details the actions taken when False (move files, rename folders, clean up backups). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detect and fix') and resources ('GDrive folder structure issues'), and it enumerates the exact types of issues scanned (unknown folders, root-level files, empty managed folders, stale backup folders). This distinguishes it from sibling tools like 'gdrive_fix_permissions' or 'gdrive_sync', which address different aspects of GDrive management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—specifically for addressing folder structure issues in GDrive. However, it does not explicitly state when not to use it or name alternatives among sibling tools (e.g., 'gdrive_fix_permissions' for permission issues or 'gdrive_sync' for synchronization). The guidance is implied but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename documents from old naming conventions to the standard format.
Standard format: YYYYMMDD_PatientName_Institution_Category_DescriptionEN.ext
In dry_run mode (default), returns a preview of proposed renames without making any changes. Set dry_run=False to execute the rename.
Args: dry_run: If True (default), only preview changes. Set False to execute. en_descriptions: Optional JSON object mapping doc_id → English description (e.g. '{"15": "BloodResultsPreCycle3", "42": "CTAbdomen"}'). If not provided, keeps existing descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| en_descriptions | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the dry-run vs. execute behavior (critical for safety), explains the default mode, and describes how optional descriptions are handled. It lacks details on permissions, errors, or rate limits, but covers core behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and standard format, followed by dry-run explanation and parameter details in a structured 'Args' section. Every sentence adds value: no fluff, efficient communication of key information in a logical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and no annotations, the description does a strong job explaining parameters and behavior. Since an output schema exists, it needn't detail return values. However, it could briefly mention what the output looks like (e.g., preview list or confirmation) for better completeness, but it's largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does: it explains both parameters clearly—dry_run's purpose and default, and en_descriptions' optional JSON mapping with examples—adding essential meaning beyond the bare schema. This is excellent compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rename' and the resource 'documents', specifying the transformation from 'old naming conventions' to a detailed 'standard format' with a concrete example. It distinguishes itself from siblings like 'update_document_category' or 'enhance_documents' by focusing solely on renaming for standardization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: to rename documents to a specific standard format. It implicitly suggests usage when documents have non-standard names, but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'update_document_category' might be for different changes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a soft-deleted document from trash.
Args: doc_id: The local document ID to restore.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Restore') but doesn't mention permissions required, whether restoration is reversible, side effects on related data, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a brief parameter explanation. There's no wasted text, and every sentence earns its place, making it highly efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral details, it leaves gaps in understanding permissions, side effects, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'doc_id' by specifying it's a 'local document ID to restore', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this effectively compensates, though it doesn't detail format constraints (e.g., ID source).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Restore') and resource ('soft-deleted document from trash'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_trash' or 'delete_document', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_trash' (to see what's deletable) or 'delete_document' (the inverse operation). It mentions 'soft-deleted' but doesn't clarify prerequisites or exclusions, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the activity log with filters.
Args: session_id: Filter by session. agent_id: Filter by agent. tool_name: Filter by tool name. status: Filter by status (ok, error, timeout). date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). text: Search in input/output summaries. limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| agent_id | No | ||
| tool_name | No | ||
| status | No | ||
| date_from | No | ||
| date_to | No | ||
| text | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions filtering and a limit parameter, but doesn't describe key behaviors: whether the search is case-sensitive, how results are ordered, if pagination is supported beyond the limit, or what the output looks like. For a search tool with 8 parameters and no annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a brief purpose statement followed by a bulleted list of parameters with concise explanations. Every sentence earns its place, and it's front-loaded with the core functionality. There's no wasted verbiage, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations) and the presence of an output schema, the description is moderately complete. It covers parameter semantics well but lacks behavioral context like search behavior or result formatting. The output schema likely handles return values, so the description doesn't need to explain those, but it should address more operational details for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema, which has 0% schema description coverage. It clearly explains each parameter's purpose, such as 'Filter by session' for session_id and 'Search in input/output summaries' for text. This compensates well for the schema's lack of descriptions, though it doesn't detail format specifics like date formats or status enum values beyond 'ok, error, timeout'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the activity log with filters.' This specifies the verb ('search') and resource ('activity log'), and the mention of 'filters' hints at its scope. However, it doesn't explicitly differentiate from sibling tools like 'search_calendar_events' or 'search_documents', which have similar search patterns but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether the activity log must be populated or if specific permissions are required. There's also no indication of when not to use it or what other tools might be better for related tasks, like 'get_activity_stats' for aggregated data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search stored calendar entries by text, date, or medical relevance.
Args: query: Text to search in summary and description. date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). is_medical: Filter to medical events only when True. limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| date_from | No | ||
| date_to | No | ||
| is_medical | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, how results are structured, whether there's pagination, or what happens when no results are found. For a search tool with 5 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose, though the parameter explanations could be slightly more concise. The information is front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and the description covers all parameters, the description is reasonably complete for a search tool. However, the lack of behavioral context (permissions, result structure, error conditions) and usage guidelines relative to sibling tools leaves gaps that prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section. It clarifies what each parameter does (e.g., 'query' searches summary and description, 'is_medical' filters to medical events only) and provides format guidance for dates. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches calendar entries by specific criteria (text, date, medical relevance), providing a specific verb ('search') and resource ('calendar entries'). However, it doesn't explicitly differentiate from sibling tools like 'get_calendar_event' or 'search_activity_log', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_calendar_event' (which appears to retrieve a single event) or other search tools in the sibling list. There's no mention of prerequisites, limitations, or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the conversation archive by text, type, date, or tags.
Returns entries with truncated content (500 chars). Use get_conversation for full text of a specific entry.
Args: text: Full-text search query. entry_type: Filter by type: summary, decision, progress, question, note. participant: Filter by participant: claude.ai, claude-code, oncoteam. date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). tags: Comma-separated tags to filter by (all must match). limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| entry_type | No | ||
| participant | No | ||
| date_from | No | ||
| date_to | No | ||
| tags | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behavioral traits: returns entries with truncated content (500 chars), mentions filtering capabilities, and implies a search operation rather than data modification. However, it doesn't mention pagination behavior, rate limits, or authentication requirements that might be relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with the core purpose, then behavioral detail (truncated content), then usage guidance, then parameter documentation. Every sentence earns its place with zero wasted words. The parameter documentation is clearly formatted but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, search functionality) and the presence of an output schema (which means return values don't need explanation), the description is complete. It covers purpose, behavioral constraints (truncation), usage guidance, and comprehensive parameter semantics. With no annotations, it provides all necessary context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. With 0% schema description coverage and 7 parameters, the description fully compensates by explaining each parameter's purpose, format, and constraints (e.g., 'YYYY-MM-DD' for dates, 'comma-separated tags', specific enum values for entry_type and participant). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the conversation archive by text, type, date, or tags.' It specifies the verb ('Search'), resource ('conversation archive'), and scope ('by text, type, date, or tags'). It also distinguishes from sibling 'get_conversation' by noting that tool provides full text while this returns truncated content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: 'Use get_conversation for full text of a specific entry.' This clearly differentiates between search (multiple results, truncated) and retrieval (single entry, full text). The context of searching vs. retrieving specific entries is well-established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search medical documents by text, institution, category, or date range.
Multi-term queries (e.g. "CEA labs") use AND semantics — all terms must match somewhere. Results are ranked by relevance when text is provided: filename/description matches rank highest, then AI summaries, then tags.
Args: text: Search query (searches filename, institution, description, AI summary, tags, and structured metadata). Multiple words are AND-ed together. institution: Filter by institution code (e.g. NOUonko, OUSA). category: Filter by category (labs, report, imaging, pathology, genetics, surgery, surgical_report, prescription, referral, discharge, discharge_summary, chemo_sheet, vaccination, dental, preventive, other). date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). limit: Maximum results to return (max 200). offset: Skip this many results (for pagination).
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| institution | No | ||
| category | No | ||
| date_from | No | ||
| date_to | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: AND semantics for multi-term queries, ranking logic (relevance based on text matches), and pagination support (limit/offset). It also specifies the max limit (200). However, it doesn't cover aspects like error handling, performance expectations, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose, followed by behavioral details, then a clear 'Args:' section with bullet-point explanations. Every sentence adds value—no redundancy or fluff. It efficiently conveys complex information in a readable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, search functionality) and no annotations, the description does an excellent job covering purpose, behavior, and parameters. Since an output schema exists, it doesn't need to explain return values. The main gap is lack of explicit usage guidelines compared to siblings, but overall it's highly complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for all 7 parameters: explains what 'text' searches (filename, institution, etc.), gives examples for 'institution' and 'category', clarifies date formats, and defines 'limit' and 'offset' for pagination. This adds significant value beyond the bare schema, making parameters understandable and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search medical documents by text, institution, category, or date range.' It specifies the resource (medical documents) and the search dimensions, distinguishing it from siblings like 'list_documents' (which likely lists without search) and 'get_document_by_id' (which retrieves by ID). The specificity helps the agent understand this is a filtered search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the listed search parameters but does not explicitly state when to use this tool versus alternatives. For example, it doesn't compare to 'list_documents' (which might return all documents without filtering) or 'search_research' (which might search different content). The guidance is limited to the tool's own functionality without sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search stored email entries by text, date, sender, or medical relevance.
Args: query: Text to search in subject, body snippet, and sender. date_from: Filter from this date (YYYY-MM-DD). date_to: Filter to this date (YYYY-MM-DD). sender: Filter by sender email or name (partial match). is_medical: Filter to medical emails only when True. limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| date_from | No | ||
| date_to | No | ||
| sender | No | ||
| is_medical | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through 'search' and specifies filtering capabilities, but it doesn't cover critical aspects like pagination, rate limits, error handling, or response format. The mention of 'limit' hints at result bounding, but behavioral traits are incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a purpose statement followed by a bullet-point list of parameters, each with a brief explanation. Every sentence earns its place by clarifying the tool's function or parameter usage, with no redundant or vague language. It's front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no annotations, but with an output schema), the description is largely complete for a search operation. It covers all parameters thoroughly and states the purpose clearly. The output schema existence means return values needn't be explained, but behavioral aspects like error handling or performance are omitted, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description fully compensates by detailing all 6 parameters with clear semantics. It explains what each parameter filters (e.g., 'query' searches subject, body snippet, and sender; 'is_medical' filters to medical emails) and provides format hints (e.g., 'YYYY-MM-DD' for dates), adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('search') and resource ('stored email entries'), and it distinguishes from siblings by focusing on email search rather than documents, conversations, or other entities. It explicitly lists the searchable fields (text, date, sender, medical relevance), making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_documents' or 'search_conversations', nor does it mention prerequisites such as authentication or data availability. It lacks context about typical use cases or limitations, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search prompt logs — all AI calls made during document processing.
Returns a list of prompt log entries (without full prompts for brevity). Use get_prompt_log_entry to see full prompts and responses for a specific entry.
Args: call_type: Filter by type: 'ocr', 'summary_tags', 'structured_metadata', 'filename_description'. document_id: Filter by document ID. status: Filter by status ('ok' or 'error'). date_from: Filter from date (YYYY-MM-DD). date_to: Filter to date (YYYY-MM-DD). text: Search in prompts and responses. limit: Max results (1-200, default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| call_type | No | ||
| document_id | No | ||
| status | No | ||
| date_from | No | ||
| date_to | No | ||
| text | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool returns ('list of prompt log entries without full prompts') and mentions a default limit behavior ('default 50'), which adds useful context beyond the input schema. However, it doesn't disclose other important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or error handling. For a search tool with 7 parameters, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It begins with a clear purpose statement, then describes the return value and relationship to sibling tool, followed by a well-organized parameter section. Every sentence earns its place: the first sentence defines the tool, the second describes returns, the third provides usage guidance, and the parameter explanations are essential given the schema's 0% description coverage. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, but with output schema), the description is mostly complete. The parameter semantics are thoroughly covered, and the relationship to the sibling tool is clear. The presence of an output schema means the description doesn't need to explain return values. However, for a search tool with no annotations, it could benefit from more behavioral context about read-only nature, performance characteristics, or error scenarios to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the input schema. With 0% schema description coverage and 7 parameters, the schema only shows types and defaults. The description adds crucial semantic information: it explains what each parameter filters by (e.g., 'Filter by type', 'Filter by document ID', 'Search in prompts and responses'), provides allowed values for 'call_type' and 'status', specifies date format ('YYYY-MM-DD'), and gives range/constraint information for 'limit' ('1-200, default 50'). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'prompt logs — all AI calls made during document processing' and returns 'a list of prompt log entries', providing specific verb ('search') and resource ('prompt logs'). It distinguishes from sibling 'get_prompt_log_entry' by noting this returns entries 'without full prompts for brevity' while the sibling shows full details. However, it doesn't explicitly differentiate from other search tools like 'search_documents' or 'search_activity_log' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool versus alternatives: it explicitly states 'Use get_prompt_log_entry to see full prompts and responses for a specific entry,' giving a direct alternative for detailed viewing. However, it doesn't mention when NOT to use this tool (e.g., for non-prompt-log searches) or compare it to other search tools in the sibling list, leaving some usage boundaries implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search saved research entries by text and/or source.
Args: text: Search in title, summary, and tags. source: Filter by source (e.g. pubmed, clinicaltrials). limit: Maximum results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| source | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the search functionality but lacks details on permissions, rate limits, pagination, or error handling. For a search tool with zero annotation coverage, this is insufficient to inform the agent about operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by bullet-point parameter explanations. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, but lacks behavioral context and usage guidelines. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to explain them, but overall it leaves gaps in guiding the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains each parameter: 'text' searches in title, summary, and tags; 'source' filters by examples like pubmed; and 'limit' specifies maximum results. This adds meaningful context beyond the bare schema, though it could benefit from more detail on source options or text matching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search saved research entries by text and/or source.' It specifies the verb (search) and resource (saved research entries), making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'list_research_entries' or 'search_documents', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'list_research_entries' (which might list all entries without filtering) or 'search_documents' (which might search different content), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different patient for this connection.
After calling this, all subsequent tool calls will use the selected patient's data. The selection persists across requests.
Args: patient_slug: Patient slug or UUID (e.g. 'q1b', 'e5g').
| Name | Required | Description | Default |
|---|---|---|---|
| patient_slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool changes connection state, the selection persists across requests, and it affects all subsequent tool calls. However, it doesn't mention potential side effects, error conditions, or what happens if an invalid patient slug is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: a clear purpose statement followed by behavioral context, then parameter documentation. Every sentence earns its place with no wasted words. The two-sentence format with a parameter explanation is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (state-changing operation), no annotations, and an output schema present, the description is reasonably complete. It explains the core functionality and persistence behavior well. However, for a state-changing tool with no annotations, it could benefit from mentioning error handling or confirmation of successful selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description adds significant value by explaining what 'patient_slug' represents and providing examples ('q1b', 'e5g'). This compensates well for the schema's lack of documentation, though it doesn't specify format constraints or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Switch') and resource ('patient'), distinguishing it from all sibling tools which perform different operations like adding, analyzing, or retrieving data. It explicitly describes changing the active patient context for the connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: to switch patients for subsequent operations. It mentions that the selection persists across requests, which is helpful guidance. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a persistent key-value pair for an agent.
Upserts: creates the key if new, updates if it already exists.
Args: key: State key name (e.g. "last_briefing_date", "treatment_protocol"). value: JSON string value to store. agent_id: Agent identifier (default: oncoteam).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | ||
| agent_id | No | oncoteam |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the upsert behavior (creates or updates) and mentions persistence, which are useful behavioral traits. However, it lacks details on permissions required, rate limits, error conditions, or what the output looks like. For a mutation tool with zero annotation coverage, this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clarifying upsert note, and then a structured 'Args:' section. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, mutation operation) and no annotations, the description does well by explaining parameters and behavior. An output schema exists, so return values needn't be described. However, it could improve by addressing permissions or error handling, keeping it from a score of 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'key' is explained with examples ('last_briefing_date', 'treatment_protocol'), 'value' as a 'JSON string value to store', and 'agent_id' with its default ('oncoteam'). This goes beyond the bare schema, though it doesn't fully detail constraints like key format or value validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set a persistent key-value pair for an agent' with 'Upserts: creates the key if new, updates if it already exists.' This specifies the verb (set/upsert), resource (key-value pair), and scope (for an agent). However, it doesn't explicitly differentiate from sibling tools like 'get_agent_state' or 'list_agent_states', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_agent_state' for retrieval or 'list_agent_states' for listing, nor does it specify prerequisites, exclusions, or appropriate contexts. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create the folder structure in a GDrive root folder (patient-type-aware).
Idempotent: checks for existing folders by name before creating. Handles both bilingual and legacy EN-only folder names (renames old to bilingual). Oncology patients skip general-only folders; general patients skip oncology-only.
Args: root_folder_id: The Google Drive folder ID to create subfolders in.
| Name | Required | Description | Default |
|---|---|---|---|
| root_folder_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: idempotency (checks existing folders), handling of bilingual/legacy names (renames old), and patient-type logic (oncology/general folder skipping). It does not cover permissions, error handling, or rate limits, but provides substantial operational context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a clear purpose statement followed by behavioral details and parameter explanation. Every sentence adds value—no redundancy or fluff. It is front-loaded with the main action and remains focused throughout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (patient-type logic, idempotency) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, behavior, and parameter semantics adequately, with no annotations to rely on. The output schema likely details the created structure, so the description need not explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, but the description compensates fully by explaining 'root_folder_id' as 'The Google Drive folder ID to create subfolders in.' This adds essential meaning beyond the bare schema, clarifying the parameter's role and format expectation, which is critical given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create the folder structure') and resource ('in a GDrive root folder'), with additional specificity about being 'patient-type-aware'. It distinguishes itself from sibling tools like 'gdrive_set_folder' or 'gdrive_sync' by focusing on structured folder creation rather than general folder operations or synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when setting up a patient-type-aware folder structure in a Google Drive root folder. It implicitly suggests alternatives by mentioning specific behaviors (e.g., oncology vs. general patients), but does not explicitly name when not to use it or list alternative tools like 'gdrive_set_folder' for simpler folder operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store parsed lab values from a document for trend tracking.
Includes deduplication checks:
If document_id already has stored values, returns skipped (unless force=True to update/replace).
If another document has values for the same lab_date, warns about collision (stores anyway but flags it).
Standardized parameter names: WBC, ABS_NEUT, ABS_LYMPH, PLT, HGB, ANC, ALT, AST, GMT, ALP, BILIRUBIN, CREATININE, eGFR, CEA, CA19_9, SII, NE_LY_RATIO
Args: document_id: Source document ID (should be a labs document). lab_date: Date of the lab test (YYYY-MM-DD). values: JSON array of objects, each with: parameter, value, unit, and optionally reference_low, reference_high, flag. Example: [{"parameter": "WBC", "value": 6.8, "unit": "10^9/L", "reference_low": 4.0, "reference_high": 10.0, "flag": ""}] force: If True, store even if document already has values (replaces existing via INSERT OR REPLACE).
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| lab_date | Yes | ||
| values | Yes | ||
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: deduplication logic (skipping if document_id exists, warning on lab_date collisions), mutation effects (stores or updates data), and the impact of the 'force' parameter. It doesn't cover rate limits or auth needs, but given the context, this is sufficient for a high score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement, usage details, and parameter explanations. It could be slightly more front-loaded by moving the standardized parameter names list to an appendix, but overall, every sentence earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with deduplication logic), no annotations, and an output schema present (which handles return values), the description is complete. It covers purpose, usage, behavior, and parameter semantics thoroughly, leaving no gaps for the agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose (e.g., 'document_id: Source document ID (should be a labs document)'), provides an example for 'values', and clarifies the effect of 'force'. This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('store') and resource ('parsed lab values from a document'), and distinguishes it from siblings by focusing on lab value storage for trend tracking, unlike tools like 'analyze_labs' or 'compare_labs' which process or compare data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance, including when to use (for storing lab values with deduplication checks) and when not to use (unless 'force=True' to update/replace). It also implies alternatives by noting that if 'document_id already has stored values, returns skipped', suggesting tools like 'get_lab_summary' might be used to check existing data first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import files from Google Drive into oncofiles.
Walks category/year-month subfolders, detects new and changed files, downloads them, uploads to Files API, and stores metadata.
Args: dry_run: Preview changes without importing. enhance: Run AI summary/tag generation on new/changed files (default True).
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| enhance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the multi-step process (walking folders, detecting changes, downloading, uploading, storing metadata) and the effect of parameters (dry_run for preview, enhance for AI processing). However, it doesn't mention potential side effects like rate limits, authentication requirements, or what happens with existing files, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The workflow details are necessary for understanding the tool's behavior. The parameter explanations are concise and directly relevant. There's minimal wasted verbiage, though the structure could be slightly improved by separating the workflow description from parameter details more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step import process), no annotations, and the presence of an output schema (which handles return values), the description provides substantial context about the workflow and parameters. It covers the core behavior well but could benefit from mentioning prerequisites (like authentication setup) or potential limitations given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters, the description fully compensates by clearly explaining both parameters: 'dry_run: Preview changes without importing' and 'enhance: Run AI summary/tag generation on new/changed files (default True)'. This adds essential meaning beyond the bare schema types, making the parameter purposes and effects completely clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Import files from Google Drive into oncofiles') and resource ('files'), distinguishing it from siblings like 'sync_to_gdrive' (which presumably exports) and 'gdrive_sync' (which may be a different sync operation). It provides a detailed workflow explanation that makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the workflow description ('Walks category/year-month subfolders...'), but does not explicitly state when to use this tool versus alternatives like 'gdrive_sync' or 'reconcile_gdrive'. It provides some guidance through parameter defaults but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export documents from oncofiles to Google Drive.
Uploads documents to organized category/year-month folders with manifest and metadata markdown files.
Args: dry_run: Preview changes without exporting.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it exports documents, organizes them into 'category/year-month folders', creates 'manifest and metadata markdown files', and offers a dry-run mode. However, it doesn't cover important aspects like authentication requirements, rate limits, error handling, what happens with existing files, or whether this is a one-time or recurring sync operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, behavioral details, and parameter explanation. It's front-loaded with the core purpose, followed by implementation details. While efficient, the second sentence could be slightly more concise by combining folder organization and file creation aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a data export/mutation tool with no annotations, 1 parameter (0% schema coverage), but with an output schema, the description is moderately complete. It covers the core operation and parameter meaning, but lacks important context about authentication, error conditions, what specific documents are exported, and how the output schema relates to the operation. The presence of an output schema reduces but doesn't eliminate the need for more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'dry_run' beyond what the schema provides (0% coverage). It explains that dry_run 'Preview changes without exporting,' clarifying its purpose as a test mode. Since there's only one parameter and the description covers it adequately, this earns a strong score despite the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export documents from oncofiles to Google Drive' with specific verb ('Export') and resources ('documents from oncofiles to Google Drive'). It distinguishes from siblings like 'sync_from_gdrive' (reverse direction) and 'export_document_package' (different export format), though not explicitly. However, it doesn't fully differentiate from 'gdrive_sync' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'dry_run' parameter explanation ('Preview changes without exporting'), suggesting this tool should be used for actual exports or testing. However, it lacks explicit guidance on when to use this versus alternatives like 'export_document_package' or 'gdrive_sync', and doesn't mention prerequisites (e.g., authentication, folder setup) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system health overview: sync history, document counts, resource usage, and errors.
Returns a comprehensive status report useful for monitoring and debugging. Includes 7-day sync statistics, recent sync runs, memory usage, and document counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's read-only nature through 'Get' and 'Returns', and describes the comprehensive report format. However, it doesn't mention potential side effects, authentication requirements, rate limits, or error handling, leaving behavioral gaps for a system health tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded: the first states the core purpose, the second explains the return value's utility, and the third provides specific data included. No wasted sentences, though minor repetition exists between 'system health overview' and 'comprehensive status report'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (system monitoring with multiple data types), no annotations, but an output schema exists, the description provides good coverage. It explains what data is included and the tool's purpose, though it could better address behavioral aspects like permissions or limitations given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool returns, which is valuable context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get system health overview' followed by specific components (sync history, document counts, resource usage, errors). It distinguishes from siblings by focusing on system monitoring rather than patient/document operations, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'useful for monitoring and debugging' and lists specific data included (7-day sync statistics, recent sync runs, memory usage, document counts). However, it doesn't explicitly state when to use this versus other diagnostic tools or provide clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the category of a document.
Use this to recategorize documents (e.g. from 'other' to 'reference').
Args: doc_id: The integer database ID of the document. category: New category (labs, report, imaging, pathology, genetics, surgery, surgical_report, prescription, referral, discharge, discharge_summary, chemo_sheet, vaccination, dental, preventive, reference, advocate, other).
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| category | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is an update/mutation tool ('Update the category'), implying it modifies data, but doesn't disclose behavioral traits like permission requirements, whether changes are reversible, side effects, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with a clear purpose statement, follows with usage guidance, and then details parameters in a formatted 'Args:' section. Every sentence earns its place, with no wasted words, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, mutation operation) and no annotations, the description does well: it explains purpose, usage, and parameters thoroughly. Since there's an output schema (per context signals), it doesn't need to describe return values. However, it could improve by adding more behavioral context (e.g., error cases or prerequisites), keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining both parameters: 'doc_id' as 'The integer database ID of the document' and 'category' with a detailed list of allowed values. This adds substantial meaning beyond the bare schema, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update the category of a document' with the verb 'update' and resource 'document category'. It provides a concrete example ('from "other" to "reference"'), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'validate_categories' or 'rename_documents_to_standard', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance with 'Use this to recategorize documents', which implies when to use it. However, it doesn't specify when NOT to use it or mention alternatives among sibling tools (e.g., 'validate_categories' might be related). The guidance is helpful but incomplete, lacking explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update specific fields in the patient clinical context.
Merges the provided updates into the current context. Nested dicts (like biomarkers, treatment, physicians) are merged recursively. Persisted to database for durability.
Args: updates_json: JSON object with fields to update. Example: '{"treatment": {"current_cycle": 3}}'
| Name | Required | Description | Default |
|---|---|---|---|
| updates_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: it describes merging behavior ('Merges the provided updates into the current context... recursively'), persistence ('Persisted to database for durability'), and hints at data structure ('Nested dicts like biomarkers, treatment, physicians'). However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by behavioral details and an example. There is minimal waste, though the example could be slightly more concise. Overall, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with merging behavior), no annotations, and an output schema present (which reduces the need to describe return values), the description is moderately complete. It covers key behavioral aspects but lacks details on error cases, permissions, or integration with sibling tools, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'updates_json' is a 'JSON object with fields to update' and provides an example ('{"treatment": {"current_cycle": 3}}'), clarifying the parameter's purpose and format. This compensates well for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update specific fields in the patient clinical context.' It specifies the verb ('update') and resource ('patient clinical context'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'update_treatment_event' or 'update_document_category', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing patient context), exclusions, or comparisons to sibling tools like 'get_patient_context' or 'update_treatment_event'. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a treatment event's title, notes, or metadata.
Args: event_id: The treatment event ID to update. title: New title (optional). notes: New notes (optional). metadata: New metadata JSON string (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | ||
| title | No | ||
| notes | No | ||
| metadata | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe any behavioral traits such as permission requirements, whether changes are reversible, error handling (e.g., if event_id doesn't exist), or response format. The description lacks critical context for a mutation tool, leaving gaps in understanding how it behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated in the first sentence and parameter details in a structured 'Args:' section. Every sentence earns its place by adding necessary information, though the parameter descriptions are brief and could be slightly more detailed without sacrificing conciseness. No redundant or wasted text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 4 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral context (e.g., side effects, error cases) and usage guidelines. For a mutation tool without annotations, this leaves notable gaps, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation in the schema. It adds significant value by listing all four parameters (event_id, title, notes, metadata) with brief semantics: event_id is 'the treatment event ID to update,' and the others are 'new' values that are 'optional.' It also clarifies that metadata is a 'JSON string.' This effectively documents the parameters, though it could provide more detail on formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('treatment event') along with specific fields that can be modified ('title, notes, or metadata'). It distinguishes from siblings like 'add_treatment_event' (creation) and 'delete_treatment_event' (deletion), though it doesn't explicitly mention these alternatives. The purpose is specific but could be slightly more differentiated from other update tools like 'update_document_category' or 'update_patient_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing event ID), when not to use it (e.g., for creating new events), or compare it to sibling tools like 'get_treatment_event' for viewing or 'delete_treatment_event' for removal. Usage is implied only through the action 'update,' with no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a medical document to persistent storage.
The filename should follow the standard convention: YYYYMMDD_PatientName_Institution_Category_DescriptionEN.ext (e.g. 20260227_PatientName_NOU_Labs_BloodResultsBeforeCycle2.pdf)
Legacy formats (space+dash, underscore-separated) are also accepted and auto-parsed. Separators: underscores only. Description: English, CamelCase.
Args: content: Base64-encoded file content. filename: Document filename in standard or legacy format. mime_type: MIME type of the document.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | Yes | ||
| mime_type | No | application/pdf |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool stores documents persistently and auto-parses legacy filename formats, which are useful behavioral traits. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens on successful upload (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The filename convention details are necessary but could be more efficiently structured. The 'Args:' section clearly separates parameter semantics from the introductory text, though some redundancy exists in filename explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and an output schema present, the description provides strong parameter semantics and clear purpose. It covers filename conventions thoroughly. The main gap is lack of behavioral context about permissions, errors, or integration with sibling tools, but the output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantic information for all 3 parameters: content requires Base64 encoding, filename follows specific naming conventions with examples, and mime_type has a default value mentioned. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Upload a medical document') and target resource ('to persistent storage'), distinguishing it from sibling tools like 'delete_document', 'get_document', or 'view_document'. The verb 'upload' is precise and differentiates it from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through filename conventions and legacy format acceptance, but doesn't explicitly state when to use this tool versus alternatives like 'sync_to_gdrive' or 'enhance_documents'. No explicit guidance on prerequisites, timing, or tool selection criteria is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and fix document categories by comparing with AI-detected document types.
Checks each document's category against its structured_metadata.document_type. Reports mismatches and optionally corrects them.
Args: dry_run: If True (default), report mismatches without fixing. If False, update categories and move GDrive files.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it 'checks each document's category', 'reports mismatches', and 'optionally corrects them' with a dry-run mode. It also mentions moving GDrive files when correcting, which adds useful context. However, it doesn't cover aspects like permissions needed, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the first sentence stating the core purpose. The second sentence elaborates on the process, and the Args section clearly explains the parameter. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation and correction with file operations), no annotations, and an output schema present, the description is mostly complete. It explains what the tool does, how it behaves, and the parameter's effect. However, it could benefit from mentioning the output format or any limitations, though the output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining the 'dry_run' parameter's semantics: 'If True (default), report mismatches without fixing. If False, update categories and move GDrive files.' This adds clear meaning beyond the schema's type and default. Since there's only one parameter, the description adequately covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validate and fix document categories') and resources ('document categories', 'AI-detected document types'). It distinguishes itself from sibling tools like 'update_document_category' by focusing on validation against structured metadata rather than direct updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'validate and fix document categories by comparing with AI-detected document types', suggesting it's for correcting mismatches between categories and document types. However, it lacks explicit guidance on when to use this tool versus alternatives like 'update_document_category' or 'enhance_documents', and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a document and return its content for Claude to read.
Returns the actual file content (image or PDF) inline so Claude can see and analyze it directly.
Args: file_id: The Anthropic Files API file_id.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's core behavior (downloads and returns file content inline) and specifies supported formats (image or PDF). However, it doesn't mention authentication requirements, rate limits, file size constraints, or error conditions that would be important for a download operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by important behavioral details, then parameter documentation. Every sentence earns its place, with zero redundant information. The structure (purpose → behavior → args) is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter download tool with no annotations or output schema, the description provides good coverage of purpose, behavior, and parameter meaning. It could be more complete by mentioning authentication needs or error handling, but given the tool's relative simplicity, it's mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description fully compensates by clearly explaining what 'file_id' represents ('The Anthropic Files API file_id'). This adds crucial semantic meaning beyond the bare schema, specifying the exact identifier system required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download a document'), the resource ('document'), and the outcome ('return its content for Claude to read'). It distinguishes from siblings like 'get_document' (which likely returns metadata) by emphasizing actual file content retrieval and inline analysis capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('to read and analyze document content directly'), but doesn't explicitly mention when not to use it or name specific alternatives. It implies this is for content access rather than metadata retrieval, which helps differentiate from similar tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tool set covers a comprehensive oncology domain, but there is significant overlap between several tools. For example, compare_lab_panels, compare_labs, get_lab_time_series, and get_lab_trends all deal with lab comparison/trend analysis with subtle distinctions that could confuse an agent. Similarly, multiple search tools (search_documents, search_conversations, search_activity_log, etc.) have overlapping search functionality across different data types. The descriptions help clarify boundaries, but the sheer number of similar tools creates ambiguity.
Most tools follow a consistent verb_noun or verb_noun_noun pattern (e.g., add_activity_log, get_document, search_conversations). There are minor deviations like gdrive_auth_callback (noun_verb_noun) and system_health (noun_noun), but these are exceptions. The naming is generally predictable and readable across the set, with clear action-object relationships maintained throughout.
With 79 tools, this is an extremely large set that feels overwhelming for the oncology domain. While the domain is complex, many tools could be consolidated (e.g., multiple lab analysis tools, multiple search variants). The count suggests feature creep rather than a well-scoped surface, making it difficult for agents to navigate and increasing the risk of tool misselection.
The tool surface provides remarkably complete coverage for oncology patient management. It includes document CRUD (upload, get, delete, restore), lab analysis, treatment event tracking, research integration, Google services synchronization, patient context management, and comprehensive search capabilities across all data types. There are no obvious gaps—every major workflow from data ingestion to analysis to export appears to be supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your MedNode health vault in your AI assistant — records, summaries, labs, appointments.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Personal CRM for Claude. Contacts live as plain-text files in your own Google Drive.
Give Claude only the Google Drive files you choose. Every action logged.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/peter-fusek/oncofiles'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
