cinii-mcp

Overview Schema Source Related Servers Discussions Admin

cinii_search_articles

Read-onlyIdempotent

Search CiNii Research for journal articles by keyword, title, author, journal, or year, filtering by language, data source, and full-text availability to locate Japanese and other scholarship.

Instructions

Search CiNii Research for journal articles. Returns the unified envelope.

CiNii matches catalogued metadata and ANDs a multi-word query, so an un-indexed compound returns zero even when related work exists — a ZERO_CONJUNCTION diagnostic marks this; vary the rendering rather than concluding the literature is absent. A SCRIPT_LATIN_QUERY diagnostic means the query searched romanized metadata only. The same string may behave very differently on J-STAGE (full text). Foundational monographs sit in cinii_search_books, not the article index.

language filters by the language catalogued for the record (languageType): 'ja' for Japanese-language scholarship first, 'zh' or 'ko' for Chinese or Korean work indexed in CiNii.

Input Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv3.3.0Nov 1, 2026

addedInput schema / $defs / ArticleSearchInput / properties / data_source / description

Added value: +"Data source(s), comma-separated, e.g. 'JALC', 'IRDB', 'CROSSREF', 'NDL_SEARCH', 'NACSIS_CAT', 'KAKEN', 'CIA', 'CIB', 'DATACITE', 'JDCAT'. Sent as dataSourceType. Unknown values are refused here, because CiNii answers them with zero records."

addedInput schema / $defs / ArticleSearchInput / properties / has_fulltext

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "true: only records CiNii links to full text; false: only records it does not. Sent as hasLinkToFullText.",
+  "title": "Has Fulltext"
+}

addedInput schema / $defs / ArticleSearchInput / properties / journal / description
```
Added value: +"Journal title. Sent as publicationTitle."
```

addedInput schema / $defs / ArticleSearchInput / properties / language

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 2000,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Language(s) of the records, as ISO 639-1 codes, comma-separated: 'ja', 'en', 'zh', 'ko', or 'ja,en'. Sent as languageType. Filters by the language catalogued for the record, not the language of the query.",
+  "title": "Language"
+}

addedInput schema / $defs / ArticleSearchInput / properties / query / anyOf

Added value: +[
+  {
+    "maxLength": 2000,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / $defs / ArticleSearchInput / properties / query / default
```
Added value: +null
```

changedInput schema / $defs / ArticleSearchInput / properties / query / description

Previous value: -"Search query (Japanese or English)"New value: +"Free-text search terms (Japanese or English). Optional when another criterion (an identifier, a title, a filter) is given."

removedInput schema / $defs / ArticleSearchInput / properties / query / maxLength
```
Removed value: -2000
```
removedInput schema / $defs / ArticleSearchInput / properties / query / minLength
```
Removed value: -1
```
removedInput schema / $defs / ArticleSearchInput / properties / query / type
```
Removed value: -"string"
```

addedInput schema / $defs / ArticleSearchInput / properties / researcher_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 2000,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Researcher identifier(s), comma-separated: a KAKEN researcher number, an NRID, a CiNii author ID (DA…) or a researcher CRID. Sent as researcherId.",
+  "title": "Researcher Id"
+}

addedInput schema / $defs / ArticleSearchInput / properties / resource_type

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 2000,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Resource type(s), comma-separated, as CiNii names them: e.g. 'journal article', 'departmental bulletin paper', 'conference paper', 'review article', 'book', 'Dataset'. Sent as resourceType.",
+  "title": "Resource Type"
+}

addedInput schema / $defs / ArticleSearchInput / properties / sort / description

Added value: +"Sort order. NEWEST/OLDEST = by year (publication, degree award or project start); RELEVANCE (default); CITATIONS_DESC = citation count, articles only; CRID_ASC = by CRID, cross search only; NAME_ASC/NAME_DESC, PROJECTS_DESC/PROJECTS_ASC and PRODUCTS_DESC/PRODUCTS_ASC = researcher name, number of related projects and number of related research products, researcher search only (which does not accept OLDEST)."

addedInput schema / $defs / ArticleSearchInput / properties / start / maximum
```
Added value: +10000
```
removedInput schema / $defs / ArticleSearchInput / required
```
Removed value: -[
-  "query"
-]
```

addedInput schema / $defs / SortOrder / description

Added value: +"CiNii Research OpenSearch v2 `sortorder` codes.\n\nNot every code is valid for every search type, and CiNii does not refuse\none that is not: sortorder=5 on articles is silently ignored and the\nresults come back in relevance order, a page that says it is sorted when\nit is not. Each input model therefore checks its sort against _SORT_SCOPE."

changedInput schema / $defs / SortOrder / enum

Previous value: -[
-  "0",
-  "1",
-  "4",
-  "10"
-]New value: +[
+  "0",
+  "1",
+  "4",
+  "5",
+  "6",
+  "10",
+  "20",
+  "21",
+  "30",
+  "31",
+  "40"
+]

Changed5 schema fields changedv3.2.0Oct 25, 2026

changedInput schema / $defs / ArticleSearchInput / properties / author / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / $defs / ArticleSearchInput / properties / data_source / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / $defs / ArticleSearchInput / properties / journal / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / $defs / ArticleSearchInput / properties / query / maxLength
```
Added value: +2000
```

changedInput schema / $defs / ArticleSearchInput / properties / title / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv3.0.0Aug 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is free. The description earns its keep beyond that by disclosing that multi-word queries are ANDed, that un-indexed compounds silently return zero, that SCRIPT_LATIN_QUERY means romanized-metadata-only matching, and that results differ from J-STAGE full text — all real behavioral traps not visible in the schema.

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?

Purpose is front-loaded in sentence one, and the diagnostic paragraph, though long, is dense with non-obvious failure modes rather than filler. Minor waste in "Returns the unified envelope," which is vague enough to add little without the output schema in hand.

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?

An output schema exists, so return values need not be explained, and the description covers the tool-specific gotchas an agent would otherwise get wrong (false negatives, romanized-only matching, cross-database comparison). Only the response-language and paging parameters are left entirely to the schema, a small gap for a single-param wrapper.

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

Parameters4/5

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

Although top-level coverage reads 0% (the single `params` object is undocumented), the nested schema documents most fields well, and the description adds meaning the schema does not carry: how `query` is matched (AND, romanization), and that `language` keys off catalogued languageType rather than query language. The `language` explanation partly repeats the schema's own field description, and `lang`/`count`/`start` behavior is left to the schema.

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 first sentence names a specific verb and resource ("Search CiNii Research for journal articles") and immediately scopes it against a sibling by stating "Foundational monographs sit in cinii_search_books, not the article index." An agent can tell this apart from the books and other typed-search siblings without opening a schema.

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

Usage Guidelines4/5

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

It gives explicit conditional guidance — a ZERO_CONJUNCTION diagnostic means vary the rendering rather than concluding the literature is absent, and the book alternative is named outright. It does not cover the other eight siblings (dissertations, data, all), so it stops short of a full routing rule set.

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

Deploy Server