Which integrations are available for this server?

Provides integration with the KAKEN database (Japanese Grants-in-Aid for Scientific Research) via its OpenSearch API, enabling search and retrieval of research projects and researchers.

How do I use kaken-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kaken-mcp-server AI内視鏡の研究課題を検索して" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kaken-mcp-server

by masa-med-ai

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

kaken-mcp-server

科学研究費助成事業データベース（KAKEN）の公式 OpenSearch API を Claude から利用するためのローカル MCP サーバ。claude_desktop_config.json の env 経由で KAKEN_APPID を渡せるため、Win/Mac の Claude Desktop で確実に動作する。

提供ツール：

ツール名	用途
`kaken_search_projects`	研究課題を多条件で検索（kw/qa/qb/qg/qh/qm/qc/qd/qe/qf/s1/s2/o1/od）
`kaken_search_researchers`	研究者を検索（kw/qg/qm/qh/qq/qs/qe/qd）
`kaken_get_project`	課題番号から1件の詳細取得
`kaken_get_researcher_grants`	研究者番号から関与全課題を取得（業績把握用）

0. インストール方法（3通り）

すべての方法で、先に CiNii API 利用登録でアプリケーションID（appid）を取得しておくこと。

A. Claude Desktop 拡張機能（.mcpb バンドル）— 推奨

Releases から kaken-mcp-server-x.y.z.mcpb をダウンロードし、ダブルクリック（または Claude Desktop の設定 → 拡張機能にドラッグ&ドロップ）。インストールダイアログで appid を入力するだけで使える。Node.js のインストールも不要（Claude Desktop 内蔵ランタイムで動作）。

.mcpb を自分でビルドする場合：

npm install
npm run build                 # tsc → dist/
node scripts/build-mcpb.mjs   # kaken-mcp-server-x.y.z.mcpb を生成

Note: npx @anthropic-ai/mcpb pack は使わない。新しい mcpb CLI が生成する zip （ディレクトリエントリ無し・小構成）だと Claude Desktop のインストーラが "reply was never sent" で無応答になる。scripts/build-mcpb.mjs はインストール実績のある形式（dist + production node_modules 同梱、dir エントリ + unix ファイル種別ビット付き zip）で生成する。なお npm run bundle（esbuild 単一ファイル server/index.cjs）は Claude Code プラグイン用で、.mcpb には使わない。

B. Claude Code プラグイン（マーケットプレイス経由）

/plugin marketplace add masa-med-ai/kaken-mcp-server
/plugin install kaken-search@kaken-marketplace

appid は環境変数で渡す（シェルの rc ファイル等に設定）：

export KAKEN_APPID="YOUR_APPID_HERE"

C. 手動セットアップ（claude_desktop_config.json）

以下の手順1〜3を参照。

Related MCP server: jgrants-mcp-server

1. 手動セットアップ

1-1. appid を取得

CiNii API 利用登録でアプリケーションID（appid）を取得する。

1-2. このリポジトリを準備

git clone <this-repo>  # または手動配置
cd kaken-mcp-server
npm install
npm run build

dist/index.js が生成される。

1-3. claude_desktop_config.json に登録

設定ファイルの場所：

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

以下を追記する（既存の mcpServers がある場合はその中にマージ）：

{
  "mcpServers": {
    "kaken": {
      "command": "node",
      "args": ["/絶対パス/kaken-mcp-server/dist/index.js"],
      "env": {
        "KAKEN_APPID": "YOUR_APPID_HERE"
      }
    }
  }
}

Windows の例（パス区切りに注意。バックスラッシュは \\ でエスケープ）：

{
  "mcpServers": {
    "kaken": {
      "command": "node",
      "args": ["C:\\Users\\<name>\\kaken-mcp-server\\dist\\index.js"],
      "env": {
        "KAKEN_APPID": "YOUR_APPID_HERE"
      }
    }
  }
}

設定後、Claude Desktop を再起動するとツールが利用可能になる。

2. 動作確認

Claude に以下のように依頼すれば、自動的にツールが呼ばれる：

「KAKEN で AI 内視鏡の先行研究を調べて」
「研究者番号 80802743 の科研費業績を取得して」
「19K20626 の研究課題の詳細を見せて」
「昭和大学の消化器内科学分野の課題を年度別に集計して」

3. ツール仕様

`kaken_search_projects`

引数	型	説明
`kw`	string	フリーワード検索（全フィールド対象）
`qa`	string	研究課題名で検索
`qb`	string	研究課題番号（例: `19K20626`）
`qg`	string	研究者の姓名
`qh`	string	研究者の所属機関
`qm`	string	研究者番号（8桁）
`qc`	string	研究種目（例: `若手研究`）
`qd`	string	審査区分/研究分野
`qe`	string	研究機関
`qf`	string	キーワード
`s1`	string	助成開始年度 From
`s2`	string	助成終了年度 To
`o1`	`1`-`4`	助成期間の検索条件（1=開始年度〈既定〉, 2=終了年度, 3=期間の一部, 4=全部）
`od`	`1`-`5`	ソート（1=適合度, 2=開始年新しい順〈既定〉, 3=古い順, 4=配分額多い順, 5=少ない順）
`rw`	integer	1ページの件数（20/50/100/200/500、既定100。中間値は近い許容値に切り上げ）
`start`	integer	開始位置（既定1）
`lang`	`ja` / `en`	言語（既定 `ja`）
`format`	`ai` / `table` / `json`	出力形式（既定 `ai`）

`kaken_search_researchers`

kw, qg, qm, qh（現在の所属機関）, qq（部局）, qs（職名）, qe, qd, rw, start, lang, format を受け取る。

研究者検索API（nrid.nii.ac.jp）は XML 非対応のため、内部では format=json で取得してパースしている（研究課題検索は従来どおり XML）。取得可能な検索結果は最大1000件。

`kaken_get_project`

awardNumber (必須): KAKEN研究課題番号
format: ai / json

`kaken_get_researcher_grants`

researcherNumber (必須): 研究者番号
rw: 件数（既定200。一人の研究者の全課題を取得するため大きめ）
format: ai / table / json

4. 出力形式

ai（既定）は AI に読ませやすい圧縮 Markdown：

## 1. [19K20626] IIIFとTEIを用いたオンライン翻刻支援システムの開発
- 研究代表者: 中村 覚（80802743）/ 東京大学 史料編纂所 / 助教
- 研究種目: 若手研究
- 研究期間: 2019-04-01 〜 2023-03-31
- 状態: 完了
- 配分額: 直接 ¥3,500,000 / 間接 ¥1,050,000 / 合計 ¥4,550,000
- キーワード: IIIF, TEI, 人文情報学
- URL: https://kaken.nii.ac.jp/grant/KAKENHI-PROJECT-19K20626/

table は Markdown のテーブル、json は構造化データ。

5. 開発

npm run dev      # tsx で直接実行（ホットリロード相当）
npm run build    # tsc でビルド
npm start        # node でビルド済みを実行

6. 利用上の注意

短時間の大量アクセスを避けること（KAKEN 利用規約）
APIで返る所属情報は採択時点のものであり、現在の所属とは異なる場合がある
検索結果の二次利用には KAKEN の利用規約を確認すること

参考

Available Tools

4 tools

kaken_get_projectA

研究課題番号（例: 19K20626）を指定して1件の研究課題詳細を取得する。課題番号がすでにわかっているときの専用ツール。kaken_search_projects に qb を渡すのと同等だが、用途が明確なのでこちらを優先する。

ParametersJSON Schema

Name	Required	Description	Default
`format`	No
`awardNumber`	Yes	KAKEN研究課題番号（例: 19K20626）

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It implies a read operation but does not explicitly state read-only, authentication needs, error handling for invalid numbers, or any side effects. The mention of equivalence to search adds some context but is insufficient for full transparency.

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

Conciseness5/5

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

The description is three sentences, concise and front-loaded. Every sentence adds value, with no redundant information. It efficiently conveys purpose, usage context, and comparison to sibling tools.

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

Completeness3/5

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

The description explains the tool's purpose and relation to search, but given the absence of an output schema, it does not describe the return format or fields. With low complexity (2 params), the information is partially complete but omits what the agent can expect after execution.

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

Parameters2/5

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

Schema description coverage is 50% (only awardNumber has a description). The tool's description repeats the schema description for awardNumber but adds no details about the format parameter or its enum values. Given low coverage, the description should compensate but fails to explain the second parameter.

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

Purpose5/5

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

The description clearly states the action (get details of one project) and the resource (by award number). It distinguishes from sibling tools by noting it's for when the number is already known and explicitly compares to kaken_search_projects.

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

Usage Guidelines5/5

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

The description specifies when to use this tool (when the award number is already known) and provides an alternative (kaken_search_projects with qb), stating that this tool should be prioritized due to clearer purpose.

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

kaken_get_researcher_grantsA

研究者番号（8桁）を指定して、その研究者が代表者・分担者として関与した全課題を取得する。特定研究者の科研費業績把握、時系列分析、累計配分額の集計に使う。氏名検索だと同姓同名で混じる可能性があるため、番号がわかる場合はこちらを使う。

ParametersJSON Schema

Name	Required	Description
`rw`	No
`format`	No
`researcherNumber`	Yes	研究者番号（8桁、例: 80802743）

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description must fully disclose behavior. It states that all projects (both PI and co-PI) are returned and hints at available data (e.g., cumulative allocation). However, it omits details on pagination, error handling, output format, or whether the result includes full project details. This is adequate but not thorough.

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

Conciseness4/5

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

The description is concise with three clear sentences: definition, use cases, and comparison with name search. No redundant information. However, it could be slightly more structured (e.g., bullet points for parameters) but overall efficient.

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

Completeness3/5

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

Given no output schema, the description should clarify return values. It mentions 'all projects' and implies fields like cumulative allocation, but does not specify the full output structure or pagination. For a simple tool with 3 parameters, it is minimally complete but leaves the agent guessing about the response format.

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

Parameters2/5

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

Schema description coverage is low (33%, only researcherNumber described). The description repeats the researcher number format but adds no new meaning for the other parameters (rw, format). Use cases are mentioned but not tied to parameters. The description fails to compensate for the low schema coverage.

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

Purpose5/5

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

The description clearly states the tool's purpose: retrieve all projects (grants) where a researcher is PI or co-PI using their 8-digit researcher number. It also mentions specific use cases (achievement tracking, time-series analysis, aggregation) and distinguishes itself from sibling tools by noting that name search may mix same-name individuals, reinforcing when this tool is appropriate.

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

Usage Guidelines4/5

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

The description provides explicit context for use: when you need all projects by a specific researcher and have their number. It warns against using name search due to ambiguity. However, it does not discuss when to use related sibling tools like kaken_get_project or kaken_search_projects, leaving some gaps in guidance.

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

kaken_search_projectsA

KAKEN（科学研究費助成事業データベース）から研究課題を検索する。競合・先行研究調査、特定分野の採択動向把握、申請書作成時の参考データ収集に使う。フリーワード(kw)・課題名(qa)・分野(qd)・機関(qe)・年度(s1/s2)などを組み合わせて検索でき、結果はAI向けに圧縮されたMarkdown（課題番号/代表者/所属/種目/期間/配分額/キーワード/概要）で返る。

ParametersJSON Schema

Name	Required	Description
`kw`	No	フリーワード検索（全フィールド対象）
`o1`	No	助成期間の検索条件: 1=開始年度(既定), 2=終了年度, 3=期間の一部, 4=全部
`od`	No	ソート: 1=適合度, 2=開始年新しい順(既定), 3=古い順, 4=配分額多い順, 5=少ない順
`qa`	No	研究課題名で検索
`qb`	No	研究課題番号（例: 19K20626）で検索
`qc`	No	研究種目で検索（例: '若手研究'）
`qd`	No	審査区分/研究分野で検索
`qe`	No	研究機関で検索
`qf`	No	キーワードで検索
`qg`	No	研究者の姓名で検索
`qh`	No	研究者の所属機関で検索
`qm`	No	研究者番号（8桁）で検索
`rw`	No	1ページの件数。20/50/100/200/500
`s1`	No	助成開始年度 From
`s2`	No	助成終了年度 To
`lang`	No
`start`	No	開始位置
`format`	No	出力形式。ai(既定)/table/json

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It states the output format (compressed Markdown with specific fields) and mentions that results include project number, representative, affiliation, etc. It implies a read-only search operation. However, it does not disclose potential rate limits, authentication requirements, or pagination behavior beyond the start parameter. The behavioral transparency is good but not exhaustive.

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

Conciseness4/5

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

The description is a single paragraph that front-loads the tool's purpose and use cases. It is moderately sized (about 100 characters) and every sentence adds value. It could be slightly more structured (e.g., bullet points for use cases), but it is concise and avoids redundancy.

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

Completeness3/5

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

Given 18 parameters and no output schema, the description covers the tool's purpose, use cases, and output format. However, it does not explain pagination details (e.g., how start and rw interact) or mention the output format parameter (format: ai/table/json) beyond the default. The lack of an output schema increases the need for the description to explain return values, but it only briefly mentions the Markdown content. Some completeness gaps exist.

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

Parameters3/5

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

Schema description coverage is 94%, so the baseline is 3. The description adds some value by grouping parameters (e.g., 'フリーワード(kw)・課題名(qa)・分野(qd)・機関(qe)・年度(s1/s2)') and stating they can be combined. However, it does not provide additional semantics beyond what the schema already explains for most parameters. Since coverage is high, the description's contribution is minimal.

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

Purpose5/5

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

The description clearly states the tool searches the KAKEN database for research projects, lists specific use cases (competitor/prior research, trend grasp, reference data collection), and distinguishes itself from sibling tools like kaken_get_project (which retrieves a single project) and kaken_search_researchers (which searches researchers). The verb 'search' combined with the resource 'projects' and the detailed usage scenarios provide high-purpose clarity.

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

Usage Guidelines4/5

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

The description explicitly provides usage scenarios (競合・先行研究調査、特定分野の採択動向把握、申請書作成時の参考データ収集) and mentions combining parameters. However, it does not explicitly state when not to use this tool versus alternatives (e.g., when to use kaken_get_project instead). The context is clear but lacks exclusion criteria.

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

kaken_search_researchersA

KAKEN研究者データベース（NRID）から研究者を検索する。氏名・研究者番号・所属機関・研究分野から研究者の所属・職位・URLを取得する。特定の研究者を特定したい場合や、機関・分野の研究者一覧を取得したい場合に使う。

ParametersJSON Schema

Name	Required	Description
`kw`	No	フリーワード
`qd`	No	審査区分/研究分野
`qe`	No	研究課題の研究機関（過去の所属課題も対象）
`qg`	No	研究者の姓名
`qh`	No	研究者の現在の所属機関
`qm`	No	研究者番号
`qq`	No	研究者の部局
`qs`	No	研究者の職名（例: '教授'）
`rw`	No
`lang`	No
`start`	No	開始位置。研究者検索は最大1000件まで
`format`	No

TDQS

A4/5.0

Behavior3/5

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

With no annotations, description must cover behavioral traits. It describes the tool as a search operation returning affiliation, position, and URL, implying read-only behavior. It does not discuss rate limits, authentication, or pagination details (though parameters hint at pagination). Adequate but not rich.

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

Conciseness5/5

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

Two well-structured sentences. First sentence states purpose and resource, second provides search fields and output. No extraneous information. Front-loaded and efficient.

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

Completeness4/5

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

Given 12 parameters, no output schema, and no annotations, the description sufficiently explains the tool's purpose and retrieved fields. It could mention pagination or result limits more explicitly, but the start and rw parameters imply this. Overall complete enough for effective use.

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

Parameters3/5

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

Schema coverage is 75%, so many parameters already have descriptions. The description adds value by grouping search fields (name, number, institution, field) but does not significantly expand on parameter meaning beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

Description clearly states it searches researchers from KAKEN database, lists retrieved fields (affiliation, position, URL), and specifies use cases (identifying specific researcher or listing by institution/field). This distinguishes it from sibling tools which handle projects or grants.

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

Usage Guidelines4/5

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

Explicitly describes when to use (identifying specific researcher or listing by institution/field). However, it does not mention when not to use or provide direct comparison with sibling tools, though context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.2.0Jun 25, 2026
- First observedkaken_get_project
- First observedkaken_get_researcher_grants
- First observedkaken_search_projects
- First observedkaken_search_researchers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-25 17:50 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: kaken_get_project retrieves a single project by ID, kaken_get_researcher_grants retrieves all grants for a researcher, kaken_search_projects queries projects by criteria, and kaken_search_researchers queries researchers. No overlaps.

Naming Consistency5/5

All tools follow a consistent 'kaken_<verb>_<noun>' pattern using snake_case. Verbs 'get' and 'search' are used appropriately for direct retrieval vs. querying.

Tool Count5/5

4 tools well-scoped for a read-only database access server covering search and specific retrieval for both projects and researchers.

Completeness5/5

The tool set covers all essential operations: searching for projects and researchers, retrieving a specific project, and listing all grants for a researcher. No obvious gaps given the read-only nature.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PapersFlowOAuth
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
brainkb B
org.brainkb
MCP server for querying BrainKB, a knowledge base for neuroscience knowledge graphs.
Knowledge & Memory Biology & Medicine
5324

Related MCP Servers

scholar-search-mcp
Research & Data Search
Silung
A
license
Not graded
quality
C
maintenance
An MCP server for academic paper search that integrates with AI assistants (e.g., Claude Code, Cursor), enabling them to search and retrieve academic paper metadata.
Updated 4 months ago (2026-05-22 08:35 UTC)
250
MIT
jgrants-mcp-serverofficial
Government Data Search
digital-go-jp
A
license
Not graded
quality
D
maintenance
MCP server for Japan's Jグランツ grant application system, enabling LLMs to search and retrieve subsidy information via natural language.
Updated 5 months ago (2026-04-06 07:42 UTC)
50
MIT
academic-search-mcp
Research & Data Search Open Data
r0x0d
F
license
Not graded
quality
D
maintenance
MCP server for academic research using the OpenAlex API, enabling article search, details retrieval, and author profile lookup.
Updated 3 months ago (2026-06-20 01:21 UTC)
-
kanpou-mcp
Government Data Search
yoshinaga2015
F
license
B
quality
D
maintenance
MCP server for searching Japanese government procurement notices via the Kanpou API. Enables LLMs to search by date, keyword, or detailed criteria.
Updated 10 months ago (2025-11-10 07:52 UTC)
3
1
-

kaken-mcp-server

0. インストール方法（3通り）

A. Claude Desktop 拡張機能（.mcpb バンドル）— 推奨

B. Claude Code プラグイン（マーケットプレイス経由）

C. 手動セットアップ（claude_desktop_config.json）

1. 手動セットアップ

1-1. appid を取得

1-2. このリポジトリを準備

1-3. claude_desktop_config.json に登録

2. 動作確認

3. ツール仕様

kaken_search_projects

kaken_search_researchers

kaken_get_project

kaken_get_researcher_grants

4. 出力形式

5. 開発

6. 利用上の注意

参考

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

jgrants-mcp-serverofficial

`kaken_search_projects`

`kaken_search_researchers`

`kaken_get_project`

`kaken_get_researcher_grants`