Verified Japanese company press releases with provenance (corporate number, source URL) and jobs.
Scored across 4 tools
Each tool targets a distinct resource and action: company profile retrieval, single press article fetch, company-specific press listing, and global press search. There is no overlap in functionality, making selection unambiguous.
All tool names follow a consistent verb_noun pattern: get_company_profile, get_press_article, list_company_press, search_press. The verbs are clear (get, list, search) and nouns describe the target, maintaining uniform snake_case style.
Four tools is well-scoped for a read-only press release and company profile server. Each tool serves a distinct purpose, and the count is neither too sparse nor overwhelming for the domain.
The tool surface covers the core retrieval workflows: fetching a company profile, retrieving a specific press article, listing all press for a company, and searching press across companies with category filters. There are no obvious gaps for a read-only service, as all necessary operations are present.
法人番号13桁で、企業担当者が確認して公開したプロフィール・出典・情報の日付・公開確認日時を取得します。未公開ならnot_found。確認記録は独立した事実検証ではありません。Get a published company-confirmed profile by corporate number; never returns drafts.
| Name | Required | Description | Default |
|---|---|---|---|
| corporateNumber | Yes | 法人番号13桁 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description reveals that drafts are never returned, unpublished profiles yield not_found, and that the confirmation record is not independent fact-checking. This adds meaningful behavioral context that annotations do not cover.
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 mostly efficient and front-loaded, with the core action stated first. Each clause adds value (published-only, not_found behavior, verification caveat), though the Japanese and English versions repeat some content slightly, which prevents a 5.
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 one-parameter read tool with no output schema, the description fully covers what is returned, the conditions for not_found, and an important caveat about the semantic weight of the confirmation. Nothing needed for correct invocation is missing.
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 schema description coverage at 100%, the schema already documents corporateNumber as a 13-digit string. The description merely repeats that it is a corporate number and does not add new meaning, so the baseline of 3 applies.
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 names a specific verb and resource ('Get a published company-confirmed profile by corporate number'), lists the exact data returned (profile, source, dates, confirmation timestamp), and explicitly excludes drafts and unpublished states. This clearly distinguishes it from sibling press-oriented 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 the correct use case: retrieving a profile that a company representative has confirmed and published, via a 13-digit corporate number. It states 'never returns drafts' and 'not_found' when unpublished, giving clear context and exclusions, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slug を指定して、公開プレス1件の要約(lead)・構造化された統計(facts)・関連求人・帰属(provenance)を取得します（本文は企業自身が投稿したもののみ、運営取込は著作権配慮で原本リンクを提供）。Get one published press article: summary, structured facts, related jobs, and provenance. Full body is included only for company-submitted articles; for operator-curated ones the original source link is provided instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 記事の slug（search_press の結果に含まれる） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a critical behavioral condition not visible in annotations: full body is returned only for company-submitted articles, while operator-curated ones return an original source link. This goes beyond the readOnlyHint and destructiveHint annotations and meaningfully informs the agent about response variance.
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 front-loaded, with the key content list appearing early and the important body-policy caveat in the second sentence. The bilingual repetition increases length slightly but each sentence carries distinct, necessary 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?
With only one parameter, no output schema, and strong annotations, the description provides enough context for an agent to call the tool correctly: it names the resource, the selection key, the returned data categories, and the conditional body behavior. Nothing critical is missing.
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 100%, so the schema already documents the slug parameter and its format. The description adds minimal semantic value beyond restating that a slug is used to fetch the article, so the baseline score of 3 is appropriate.
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 states a specific verb and resource: 'get one published press article' via a slug, and lists the exact returned components (lead, facts, related jobs, provenance). It also distinguishes itself from siblings by emphasizing singular retrieval of one article by slug, versus search/list 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 clearly implies the prerequisite of having a slug and, through the schema parameter note, points the agent to search_press as the source of that slug. It does not explicitly state when not to use this tool, but the singular 'one' and the slug requirement provide adequate context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
企業名または法人番号(13桁)を指定して、その企業の公開済みプレス一覧を取得します。List all published press releases for one company, by name or by 13-digit corporate number.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 最大件数（既定20, 上限50） | |
| company | Yes | 企業名（部分一致）または法人番号13桁 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the read-only and open-world aspects. The description adds little beyond the annotation: it states 'List' which aligns with the read-only hint, but does not clarify that results are limited by the limit parameter (default 20) or that the open-world hint means results may not be exhaustive. It is not contradictory, but it offers minimal added 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 concise, with the primary action front-loaded in both Japanese and English. It consists of one sentence with no fluff, and every phrase adds direct value. The bilingual redundancy is acceptable for international contexts without wasting space.
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 read-only list tool with two parameters and no output schema, the description provides the essential purpose and input. However, it does not describe the output format (e.g., an array of press releases) or any pagination behavior beyond what the limit parameter schema implies. Since no output schema exists, the description could have offered more context about the return values, but the core information needed to call the tool is present.
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 100%, and both parameters have descriptions in the schema. The tool description reiterates the key point (name or 13-digit corporate number) but adds no extra meaning beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters fully.
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/取得), the resource (published press releases), and the scoping (for one company by name or corporate number). It distinguishes from siblings by specifying 'one company', which contrasts with search_press that likely searches across companies, and from get_press_article which targets a single release.
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: it is for a single company's press releases. However, it does not explicitly mention alternatives like search_press for cross-company searches or get_press_article for a specific release. The guidance is implied rather than explicit, so it falls short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
日本企業の公開プレスを検索します。収録された法人番号・出典・投稿区分を返します。法人番号の収録は内容の事実確認を意味しません。Search published Japanese company announcements with source URLs and publication provenance. Content is not independently verified. category one of: funding(経営・資金調達), product(新商品・新サービス), partnership(事業提携・協業), hr(人事・組織), event(イベント・キャンペーン), report(調査・レポート), award(受賞・認定), store(店舗・施設).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | タグ（完全一致） | |
| limit | No | 最大件数（既定10, 上限50） | |
| query | No | キーワード（headline/lead を部分一致） | |
| since | No | この日時以降に公開（ISO8601, 例 2026-01-01） | |
| company | No | 企業名（部分一致）または法人番号13桁（完全一致） | |
| category | No | カテゴリ: funding(経営・資金調達), product(新商品・新サービス), partnership(事業提携・協業), hr(人事・組織), event(イベント・キャンペーン), report(調査・レポート), award(受賞・認定), store(店舗・施設) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful non-obvious behavioral context: listed corporate numbers do not imply fact-checking, and content is not independently verified. This goes beyond the structured 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 core description is reasonably concise and front-loaded with the verb and resource, but it repeats the category enum that is already fully specified in the input schema. The bilingual duplication adds length without new information, preventing a higher score.
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?
With no output schema, the description does explain some return values (corporate number, source, publication classification) and adds a caveat about verification. However, it leaves out details about result ordering, pagination, and how the filters combine, so an agent has to infer behavior beyond the schema.
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 100%, so the schema fully documents all six parameters. The description repeats the category enum and mentions return fields, but it does not add interpretive meaning for parameters such as query, since, or company beyond what the schema already provides.
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 states a specific verb and resource: searching published Japanese company announcements and returning registered corporate number, source, and publication classification. It is clear about what the tool does, but it does not explicitly distinguish itself from sibling tools like list_company_press, so it misses the top 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 a broad search use case through phrases like '検索します' and the category list, but it does not state when to prefer this tool over siblings or when not to use it. Usage context is present only implicitly; no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_company_profileget_press_articlelist_company_presssearch_pressRaw Japanese regulatory data for AI agents: pension, gazette, gBizINFO. x402-metered (USDC).
Japanese law, corporation & statistics data as MCP, normalized to English with source attribution.
プレニカに掲載された企業のプレスリリースと運営情報を検索・取得できる読み取り専用サーバー。出典は canonical URL に固定。
Search Japanese companies, departments and hiring signals; export CSV/XLSX with authentication.
Add one secure layer between your agents and this server.
