Skip to main content
Glama

ラジ株ナビ (Radikabunavi) - Japanese stock data from EDINET/TDnet

業績予想

get_earnings_forecast
Read-only

銘柄コード指定で、TDnet 決算短信から抽出した会社予想(来期業績・配当予想)を取得します。 会社名(companyName)は会社名の索引の現在の社名です。短信に書かれていた名前が異なるときだけ companyNameAsFiled に元の表記を付けます。companyNameIndexAsOf は索引の作成時刻です。 当期実績(速報)、前期実績、来期予想、配当予想、サプライズ判定を含みます。

データソース: TDnet 決算短信 XBRL を日次バッチで自動パース。 カバレッジ: 決算短信を提出した全上場企業(決算発表日翌日に反映)。

取得項目:

  • actual: 当期実績速報(売上・営業利益・経常利益・純利益・EPS・総資産・純資産・CF・ROE・総資産経常利益率など)

  • prior: 前期実績 ※ ordinaryIncome は IFRS・米国基準(accountingStandard が IFRS / USGAAP)の会社では経常利益ではなく税引前利益です。

  • forecast: 来期予想(数値 / レンジ上下限 / 前期比 %) period 省略時、最新の予想年度に点の予想EPS・純利益が無ければ前の年度(終わった期)の予想は返さず、forecastStatus(range=レンジのみ / non_gaap_only=利益の予想は Non-GAAP だけ / cumulative_only=通期の予想は無く累計期間の予想だけ / none=予想なし)と forecastStatusNote を付けます。

  • forecastNonGaap: 通期の利益予想を Non-GAAP でだけ開示する会社(6701 など)の Non-GAAP 営業利益・親会社に帰属する当期利益・EPS と前期比(%)。短信サマリーの予想の表の文字から読んだ値(タグなし。labels は見出しの原文、source は読んだ短信)で、株式分割の調整をしていません。 このとき forecast.operatingIncome / netIncome / eps(IFRS 等の欄)は null のままで、理想株価・スコアの計算には forecastNonGaap を使っていません。

  • forecastCumulative(period 省略時は開示日が最も新しい短信から): 第1・第3四半期累計の業績予想(通期の予想を出さず累計だけを予想する会社。6146 など)。 quarter(q1=第1四半期累計 / q3=第3四半期累計)・periodStart・periodEnd・consolidated・netSales / operatingIncome / ordinaryIncome / netIncome / eps(とレンジ)・ source(tdnetId・disclosedDate。修正開示を重ねたときは revisionTdnetId)。短信の記載値のまま(株式分割の調整をしていません)。上期(第2四半期累計)は forecastH1。

  • dividend: 配当(当期実績、来期予想、中間/期末/年間) 特別配当・記念配当の内訳(決算短信の配当の注記から読み取り。読めない・言及が無いときはフィールド自体が無い): dividend.actualSpecial(actualAnnual のうち)/ priorSpecial(priorAnnual のうち)/ forecastSpecial(forecastAnnual のうち)。 普通配当=actualAnnual − actualSpecial(予想は forecastAnnual − forecastSpecial)。 増配幅を見るときは普通配当どうしで比べてください(特別配当を含む合計どうしだと増配幅を見誤ります)。 フィールドが無いことは「特別配当が無い」ことを保証しません(注記を読めなかった場合も無くなります)。 予想の特別配当の出どころは forecastSpecialSource(予想年間配当があるときだけ): status が stated(短信の注記・修正開示に額の記載あり。 from: tanshin-note / revision-disclosure)、undetermined(修正開示に特別配当が入っているが額を読めない)、 not-stated(短信の注記・取り込んだ修正開示に額の記載が無い。含まれないことの確認ではない)。 予想を四半期短信から採った場合、年度短信の注記に内訳が無くても、四半期短信の注記にある前期の内訳を 同じ年度・同じ年間配当のときに限り actualSpecial に引き継ぎます。 短信から読めない場合は、同じ年度の有価証券報告書(配当に関する注記・経営指標等の注記・配当政策の節・期末配当の注記) から決めた特別配当で補うことがあります(年間配当が actualAnnual と一致するときのみ。補ったときは actualSpecialSource が付きます)。 この額は get_edinet_financial_data の specialDividendPerShare・summary の普通配当・get_ideal_price の配当価値と同じ関数の値です。 有報から一部の回(期末配当など)の特別配当しか分からない年度は、その額で補い actualSpecialSource.completeness が partial になります (年間の特別配当はその額より大きいことがあります)。 前期中に株式分割があり短信が前期の年間配当を「-」と記載している場合、dividend.priorAnnual は有報「剰余金の配当」の 決議から分割後の株数基準にそろえて作った値です(priorAnnualSource が付きます。検算できないときは null のまま)。

  • surprise: 前期実績対比の増減判定(業績・配当)

  • actual / prior の netIncomeBasis が total-incl-discontinued の銘柄は非継続事業があり、netIncome・eps・changeNetIncome は非継続事業を含む連結の合計、continuingNetIncome・continuingEps・changeContinuingNetIncome は継続事業だけの値です(取れなければ null。売上・営業利益・税引前、配当性向、来期予想は会社の開示どおり継続事業ベースのことがあるため、来期予想と比べるときは継続事業の値を使ってください。surprise.earnings の純利益・EPS は basis が continuing なら継続事業どうしの比較です)。

【短信がまだ無いとき】(2026-11-01) 指定した期(q1/q2/q3 など)の短信が無いのは入力の誤りではないため、エラー(isError)にはせず { hasData: false, status, reason, expectedAvailability, availablePeriods, forecast: null } で返します。 status: not_yet_disclosed=まだ開示の目安日より前 / possible_intake_delay=目安日を過ぎているのに無い(取り込みの遅れの可能性。basis に年度末・四半期末・目安日)/ not_available=この銘柄の短信をまだ持っていない / delisted=上場廃止 / not_applicable=ETF・REIT 等。存在しない銘柄コードだけが isError です。

【予想の鮮度について】(2026-09-22) period 省略時は「開示日が最新の決算短信」から通期予想を返します。 通期予想の修正は四半期短信で開示されるため、年度短信だけを見ると 数ヶ月前の古い予想になります(実測: 304社で予想純利益が変わっており、 うち63社は50%超の乖離。開示日差の中央値は86日)。 四半期短信から採った場合は forecastSource に採用した期と開示日を付与します。 このとき actual・prior・surprise・配当の実績/前期・fiscalYearEnd は**年度短信(通期)*のままで、 予想(forecast・forecastH1・dividend.forecast)だけが四半期短信の最新値です。 prior が前年同四半期になったり、surprise が四半期同士の比較になったりはしません。 四半期累計の実績は quarterlyCumulative に別フィールドで入ります。 短信が前年同期比を「-」とした項目(quarterlyCumulative.changeNotStated)は、金額から計算した増減率を quarterlyCumulative.changeComputed(source=computed。短信の記載ではない)に別の欄で返します。 quarterlyCumulative は、最新の予想の年度で開示日が最も新しい四半期短信の累計実績です(period・disclosedDate・tdnetId が出どころ)。 予想 EPS が無いため予想を年度短信から採った場合も返します。予想の短信(forecastSource)と別の短信のことがあります。 ただし年度(通期)の決算短信が保存されていない銘柄(annualActualUnavailable が付く)では、 actual・prior・surprise.earnings・配当の実績/前期・fiscalYearEnd を null で返します(四半期累計を通期実績として返さないため)。 このとき四半期短信の累計期間の末日は quarterlyPeriodEnd、年度の期末日は nextFiscalYearEnd です。 disclosedDate は短信が最初に開示された日です。期中レビューの完了に伴って同じ短信が再開示された場合は reviewCompletion(再開示の日付・tdnetId)を添えます。contentChanged=true のときだけ中身が変わっており、 disclosedDate も再開示の日付です(元の短信は originalDisclosedDate)。

【quarterlyCumulative.bps について】(2026-09-26) 四半期短信のサマリーXBRLには1株純資産(BPS)タグ自体が無いことがあります (本番実測: 四半期短信全体で約80%が欠落。q1 79%・q2 89%・q3 90%)。その場合、 equity ÷ (sharesOutstanding − treasuryShares) から算出した値を bps に補完し、 bpsSource: 'derived' を付与します。 優先株・種類株のある会社では、equity に優先株主帰属分が含まれるため補完値が 過大になることがあります。直近年度の開示済みBPSと比較して比率が0.5〜2.0倍の 範囲を外れる場合は信頼できないため補完しません(bps は null のまま、 bpsSourceNote にその旨を記載)。 ROE / ROA は補完しません。四半期短信の同タグは3/6/9ヶ月の累計利益をそのまま使うため 年率ではなく、通期短信のROE/ROAと単純比較できないためです。

period 引数:

  • 省略時: 開示日が最新の短信から通期予想

  • annual: 年度決算短信を明示指定

  • q1 / q2 / q3: 四半期決算短信 (各期とも最新の短信1本。過去の四半期ごとの実績の推移(累計と3か月単独)は get_quarterly_results で読めます)

注意:

  • surprise はアナリスト予想(コンセンサス)との比較ではありません。 本サービスはコンセンサスデータを保有していません。 surprise.earnings[].changePercent は「当期実績 vs 前期実績」の増減率(±5%超で positive/negative)、 surprise.dividend は actualVsPrior(当期実績 vs 前期実績)と forecastVsActual(来期予想 vs 当期実績)です。年間配当の合計(特別配当・記念配当を含む)どうしの比較です。 市場予想(コンセンサス)との比較は含まれません。

  • 受注高・受注残などの業種固有の指標は XBRL 標準タグ外のため含まれません。

  • 決算短信の訂正開示: corrections がある場合は訂正を反映済みです(correctedFrom が訂正前の値、 キーは 'actual.cashFlowFromOperations' のようなパス)。correctionNotices がある場合は訂正開示が 出ていますが数値は反映していません(PDF のみの訂正・XBRL を読めなかった等)。correctionNote に要約があります。 予想を四半期短信から採った場合、その短信の訂正は forecastCorrectionNote に載ります。

  • actual / prior に netSalesSource: 'edinet-annual' がある場合、その netSales は短信から読めなかったため、有価証券報告書の同じ決算期の売上で埋めた値です(netSalesSourceDocId が有報の docId。短信の開示値ではありません)。

  • 会社予想が未開示の場合、forecast.netSales 等は null になります。

  • forecastPeriodMonths は来期予想の対象期間(月数)です。通常は 12。 直近の予想が四半期短信(q1/q2/q3)から採用され、かつ直近の確定年度決算が 見つからない等の理由で判定できないときは null になります (null は「変則決算ではない」ことを意味しません。判定不能です)。 四半期短信から採用した予想は、決算期変更等で対象期間が12ヶ月以外になることが あります(四半期短信の通期予想が常に12ヶ月分とは限りません)。

  • 決算期変更による変則決算(12ヶ月以外)の場合、年度短信(annual)採用時は irregularPeriod が付きます。このとき forecast.* は変則期間分の値なので、 前期比・PER・利回りを論じる際は irregularPeriod.forecastAnnualized (年換算値)が比較に使えます。変則決算に気づかず前期と単純比較すると 大幅な減収減益に見えます。

  • forecastPeriodNote が含まれる場合、四半期短信採用時に forecastPeriodMonths が 12以外と判定されています。この場合は年換算していません(四半期短信の通期予想を 書き換えると開示値と食い違うため)。前期比較の際は forecastPeriodMonths を 確認してください。

  • 過去実績の体系的なデータは get_edinet_financial_data(有報ベース。多くの会社で約10年分(上場が浅い会社は短い))にあります。

  • period 省略時の配当予想(dividend.forecast*)は、最新の予想年度で開示日が最も新しい短信から読みます(予想EPSなどの業績予想と別の短信のことがあります)。年間が空欄で期末の予想がある短信は、中間(実績または予想)と期末を分割後の株数に揃えて足した値を forecastAnnual にします。どちらの場合も dividendForecastSource に出所を載せます。

  • dividend.forecastYearPaid(period 省略時): 予想の年度に既に支払った中間配当(四半期短信の実績欄、分割後の株数に揃えた値。{ q1, q2, q3 })。支払済みの四半期は短信で予想の列から実績の列に移るため dividend.forecastQ1〜Q3 には入りません。

  • excludedDividendDecisions(newerDisclosureWarning / newerDisclosureCheck 内)は、「剰余金の配当」 (配当の決定)のうち、採用した短信の期末の次の四半期末より前に出たため短信に載っている実績配当の 決定とみなし、修正の候補から外した開示です(特別配当・方針変更・基準日設定などを含む表題は外しません)。

  • revisionOverlay(period 省略時): 採用した決算短信より後の「業績予想の修正」「配当予想の修正」開示を、 修正開示の前回予想が短信の予想と全項目一致するときだけ予想に重ねています(通期の修正は forecast、 中間期の修正は forecastH1、第1・第3四半期累計の修正は累計の予想(理想株価の forwardTwelveMonth の材料。 period 省略時の forecastCumulative に出ます)、配当は dividend.forecast*。理想株価・get_ideal_price と同じ値)。 applied に重ねた修正(tdnetId・開示日・対象期間・修正前後)、skipped に重ねなかった修正と理由 (previous_mismatch=前回予想が一致しない、current_undetermined=未定への修正、split_driven=分割に伴う修正、 unsupported_target=翌期の修正・期間を決められない四半期累計の修正、after_unapplied_revision=前の修正を重ねられなかった、 already_in_tanshin=短信が既に修正後の値、other_consolidation_basis=短信の累計の予想と連結・個別が違う四半期累計の修正)、 asOfDate に重ねた後の予想の基準日を載せます。 特別配当・記念配当を含む配当の修正も年間の合計は重ねます。本文から金額を読めたときはその金額を dividend.forecastSpecial に入れ、 読めないとき(applied[].specialDividendUnknown)は revisionOverlay.dividendValueBasis に修正前の普通配当(理想株価の配当価値の基礎)を載せます。 disclosedDate は元の短信の開示日のままです。

  • newerDisclosureWarning が含まれる場合、採用した決算短信より後に「配当予想の修正」 「業績予想の修正」等の適時開示が出ていて、forecast/dividend の数値にまだ全部は反映していません (すべてを予想に重ねた開示は外し、reflectedRevisionIds に載せます。一部でも重ねなかった開示は残ります。 重ねなかった理由は revisionOverlay.skipped)。該当開示は get_timely_disclosures で確認できます。possibleSplitDrivenRevision が付いた 開示は株式分割に伴う機械的な配当予想の修正の可能性があり、実質的な増減配とは 限りません。disclosures[].parsedNumbers が付いている場合、その開示のXBRLから 修正前後の数値(previous/current、増減率)を取り込み済みです(無い場合はXBRL未取得 またはパース対象外)。

  • latestRevision が含まれる場合、newerDisclosureWarning で検出した開示(採用した決算短信 より後のもの)のうち、業績修正・配当修正それぞれ最新の修正後の数値です (業績と配当が別開示のことがあるため独立に選んでいます)。latestRevision.earnings は配列で、 連結・個別や対象期間ごとに別開示から選ばれることがあります(同時刻に連結業績修正と 個別業績修正が別開示で出るケース等)。forecast / dividend.forecastAnnual 等の フィールドに重ねなかった修正だけが出ます(重ねた修正は revisionOverlay.applied)。latestRevision の値で forecast 等を置き換えてはいません。この数値は決算短信本体ほど検証されておらず、 XBRLタグの解釈に会社ごとの癖がある(例: 一部企業がOperatingRevenuesタグを 営業利益の意味で使う等)ため、重要な判断には該当開示のPDF本文での確認が必要です。 latestRevision.earnings[].data.priorActual は修正開示の参考欄(前期実績)の会社記載値そのままで、 決算短信と食い違うことがあります。通期のものには priorActualCheck(同じ年度の決算短信との照合結果)を添えます。 status=eps-mismatch は純利益が一致するのに EPS だけ食い違う(修正開示側の記載の食い違い)ことを示し、 前期の EPS は priorActualCheck.comparedWith.eps(決算短信)を使ってください。

  • 修正の理由: latestRevision(earnings[].reason・dividend.reason)、newerDisclosureWarning.disclosures[].parsedNumbers.reason、 sameDayRevision.parsedNumbers[].reason、revisionOverlay.earnings / dividend.revisionReasons[tdnetId](applied・skipped の開示ごと)に、 その修正の理由の文が付きます。reason は修正の理由で、開示の XBRL(ReasonForForecastCorrection・ReasonForDividendForecastCorrection)の会社の記載をそのまま返します(要約・書き換えなし。末尾の「(注)上記の予想数値は…」の定型文も会社の記載です)。reason.status は stated=理由の文あり/not_in_xbrl=取り込み済みだが XBRL に理由の文が無い(開示 PDF の本文を確認)/not_ingested=理由の欄を取り込む前の古い記録で未確認。

  • sameDayRevision が含まれる場合、採用した決算短信と同じ日に業績予想・配当予想の修正開示が出ています。 summary に修正前後の値(修正前の値が取れないときはその旨)を載せ、parsedNumbers に修正前後・増減率の 元の値、revisionDirection に上方/下方の方向を載せます。短信の forecast / dividend がこの修正後の値と 一致するかは判定していません。

  • newerDisclosureCheck は上の検出処理が実際にどこまで確認できたかを示します。 status:no-newer-revision なら保存済み開示データの範囲内(checkedFrom〜checkedTo)で 修正は見つかりませんでした。status:unverifiable なら検証できていません (reason を参照。適時開示キャッシュの保存開始日より前の短信を採用した場合等)。 unverifiable は「修正が無い」ことを意味しません。 status:partially-checked なら、確定した範囲(checkedFrom〜checkedTo)では修正は見つかりませんでしたが、 unconfirmedDates の日は開示一覧がまだ確定していません(やのしんは夕方以降の開示を翌営業日の午後に足すことがあり、 取り直しは営業日の 15:03 と 19:00 JST。翌日以降の取り直しで、取り元の一覧と件数・最後の開示時刻(15:00 より後)まで一致すると確かめられた日は、翌営業日を待たずに確定とします。確かめられるまで未確定)。この日の修正の有無は不明で、 「修正は無い」とは言えません(note 参照)。

  • 四半期短信の原本 XBRL が失われ、取り込んだ日の日次のまとめから作り直したレコードには reconstructedFrom(source: tdnet-daily-summary)と reconstructionNote(予想を採ったときは forecastSource.reconstructionNote)が付きます。 予想の経常利益・増減率・上期予想・配当の内訳は残っていないため null / 未記載です(開示が無かったという意味ではありません)。

  • dataProvenance は、年度短信のレコードの tdnetId が空(年度短信の原本 XBRL が無く、TDnetパイプラインの 通常経路で取り込めていない)ときだけ付き、実績(actual / prior)の出どころを次の4つで示します (provenanceDetail に根拠)。 rebuilt-from-annual: 2026-05-07 に一括生成したレコードの actual / prior を、有報(EDINET)の同じ決算期の 値で作り直し済み(provenanceDetail.rebuiltAt)。 reconstructed-from-annual: 年度短信の原本が無いため、有報から作ったレコード(provenanceDetail.edinetDocId)。 来期予想は有報に無いので forecastSource の短信から採ります。 legacy-bulk-matches-annual: 一括生成のままだが、actual が有報の同じ決算期の値と一致することを確認済み (provenanceDetail.comparedFields)。 legacy-bulk: 一括生成時の値のままで、有報との一致を確認できていない、または食い違う (provenanceDetail.mismatchedFields / uncomparableReason)。 surprise.earnings はパース時と同じ式で読み出し時に再計算していますが、 surprise.earningsNote がある場合は再計算していません(前期の会計基準が 実際と異なる等の理由。reasonを参照)。priorBasisMismatch が含まれる場合、 前期実績(prior)が組み替え後の値ではない可能性があります。 rebuiltPriorBasis(source: ifrs-first-time-adoption)がある場合、当期が IFRS 移行初年度で、prior の損益・B/S・C/F・EPS・BPS は 移行初年度の有報(rebuiltPriorBasis.edinetDocId)に載っている前期の IFRS 組替値です(株数・1株配当は前期の有報の値)。staleAnnual が 含まれる場合、決算期末から長期間経過しており、このレコードが更新されていない 可能性があります。 このレコードの disclosedDate は年度短信の開示日とは限りません(一括生成時点の最新の開示の日付が入っている例がある)。 disclosedDateCheck.status が likely-not-annual-tanshin(決算期末から90日超)なら年度短信の日付ではない可能性が高く、 unverified なら未確認です。actualSource(予想を四半期短信から採った場合)では、likely-not-annual-tanshin のとき disclosedDate を null にし、記録値を recordedDisclosedDate に分けています。actualSource.tdnetId が null なのは 元の短信が特定できないためです(実績の出どころは actualSource.dataProvenance を参照)。

  • period に q1/q2/q3 を明示指定した場合、fiscalYearEnd はその四半期の累計期間の 末日(例: q1なら6/30)であり、年度の決算期末日ではありません。年度の決算期末日は nextFiscalYearEnd を参照してください(fiscalYearEndNote に同内容を付与します)。

【ordinaryIncomeToTotalAssets(総資産経常利益率)について】(2026-10-02) actual / prior / quarterlyCumulative の ordinaryIncomeToTotalAssets は決算短信サマリーの記載値で、 経常利益 ÷ 総資産(原則 期首・期末平均)の % です。IFRS・米国基準は経常利益が無いため税引前利益ベースです (ordinaryIncomeToTotalAssetsBasis: ordinaryIncome=経常利益 / profitBeforeTax=税引前利益)。 get_edinet_financial_data の roa(ROA=純利益 ÷ 期末総資産、有報ベース)とは別の指標なので、 ROA とは別の指標です。純利益ベースの ROA が必要なら netIncome ÷ totalAssets で計算できます。 tdnetId が空の年度短信レコード(dataProvenance あり)はこの値を返しません (保存値が短信の記載値ではなく純利益 ÷ 期末総資産の計算値のため)。

【roe(ROE)の定義について】(2026-10-10) actual / prior の roe は決算短信サマリーの「自己資本当期純利益率」で、純利益 ÷ 期首・期末平均の自己資本の % です (roeBasis: averageEquity)。get_edinet_financial_data の fiscalYears の roe(有報)も同じ定義にそろえています (有報の記載値。roeBasis: reported / averageEquity)。 tdnetId が空の年度短信レコード(dataProvenance あり)は期末ベースの計算値です(roeBasis: periodEndEquity)。 決算期が6か月の REIT は、その期間の率(年換算していない)です。

応答の metricLabels は英語キー→日本語指標名の対訳です。利用者向けには日本語名(例: roe→「ROE(自己資本利益率)」。roeBasis が averageEquity なら「期首・期末平均の自己資本ベース」と添える)のほうが伝わりやすくなります。 データ品質・値の異常・不具合に触れる場合も同様で、フィールド名を示すときは「発行済株式数(sharesOutstanding)」のように日本語を主・英語キーを括弧内にすると読みやすくなります。

splitCheck(分割履歴がある会社のみ): 既定は要約(splits・adjustedFields・conflict)のみ。詳細は includeSplitDetails: true で、1株あたりの値ごとに raw(短信・有報の記載値)・adjusted(使った値)・factor・basis・method と、検算の材料(純利益÷EPSで逆算した株数と分割前の株数の比)を載せます。adjusted が検算と食い違う(conflict: true 等)ときは raw を基に判断してください。

※ 本データは情報提供を目的とし、投資助言・推奨ではありません。

Input Schema

NameRequiredDescriptionDefault
codeYes証券コード(例: 6264 = マルマエ)
periodNo決算期間。**省略時は開示日が最新の短信から通期予想を返します**(通期予想の修正は四半期短信で開示されるため、annual固定だと古い予想になる)。q1/q2/q3 を明示指定するとその期の短信を返します。
includeSplitDetailsNo省略可(既定 false)。true で分割の検算の詳細(splitCheck の items・evidence・howToVerify、splitAdjustment の reason 全文)を返します。既定では splitCheck は要約(splits・adjustedFields・conflict)のみ。検算の食い違い(conflict)があるときは、false でも詳細を返します。数値は変わりません。

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / period / description
      Previous value: -"決算期間。**省略時は開示日が最新の短信から通期予想を返します**(通期予想の修正は四半期短信で開示されるため、annual固定だと古い予想になる)。q1/q2/q3 を明示指定するとその期の短信を返します(ライトプラン以上限定)。"New value: +"決算期間。**省略時は開示日が最新の短信から通期予想を返します**(通期予想の修正は四半期短信で開示されるため、annual固定だと古い予想になる)。q1/q2/q3 を明示指定するとその期の短信を返します。"
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and destructiveHint=false, yet the description still adds substantial behavior beyond them. It discloses how missing 短信 are returned with hasData:false instead of isError, describes the revisionOverlay and newerDisclosureWarning freshness logic, explains null guarantees such as dataProvenance and annualActualUnavailable, and warns that revisions parsed from XBRL are unverified. This is far more input than annotations supply.

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

Conciseness2/5

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

This description is enormously long, and much of it documents individual return fields and provenance cases rather than the tool's selection or invocation semantics. Redundancy appears, such as repeated statements that ordinaryIncomeToTotalAssets differs from get_edinet_financial_data's ROA and repeated dividend-source explanations. The first paragraph is well front-loaded, but the remainder is a dense reference manual that is hard for an agent to scan.

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

Completeness5/5

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

Because there is no output schema, the description carries the return-value burden, and it covers status enums, null semantics, revision overlay, provenance, and period edge cases such as irregular fiscal periods. No aspect of calling this tool correctly appears missing, although the coverage is far beyond the minimum needed.

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?

Schema coverage is 100%, so the schema already documents all three parameters. The description still adds meaning by explaining why omitting period is preferable (revisions arrive through quarterly 短信, so an annual-only forecast can be stale) and by describing what includeSplitDetails expands and its conflict override. It adds genuine semantics beyond the schema, but a baseline of 3 is raised only modestly because the schema already carries the parameter text.

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 opening sentence states a specific verb and resource: it retrieves company forecasts (next-period results and dividend forecasts) extracted from TDnet 決算短信, keyed by 銘柄コード. It is clearly distinguishable from siblings because it later routes historical data to get_edinet_financial_data and quarterly trends to get_quarterly_results.

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 guidance on when period should be omitted versus explicitly set to annual, q1, q2, or q3, and it names the applicable alternative tools (get_quarterly_results, get_edinet_financial_data, get_timely_disclosures) with the condition that selects each one. It does not state explicit when-not conditions; instead it relies on the reader to infer which tool not to use.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources