Skip to main content
Glama

PlugRail JP Corporate

by dev.plugrail
OverviewDiscussionsAdmin

Server Details

Search Japanese corporations and verify invoice numbers using official National Tax Agency data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 17 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
plugrail/servers
GitHub Stars
0
Server Listing
jp-calendar

TDQS

A3.6/5.0

Scored across 6 tools

Disambiguation3/5

lookup_corporate overlaps with search_corporate_by_name/address/number by also supporting candidate search and number confirmation, creating potential misselection. However, descriptions attempt to differentiate lookup_corporate as a higher-level candidate scorer versus simple prefix searches, so boundaries are partially clear.

Naming Consistency4/5

All tool names use snake_case and are descriptive. Most follow a verb_noun pattern (lookup_corporate, search_corporate_by_*, verify_invoice_number), but company_profile deviates as noun-first, which is a minor inconsistency.

Tool Count5/5

Six tools map well to distinct lookup and verification tasks: profile retrieval, confirmation/candidate search, three field-specific searches, and invoice verification. The count is well-scoped and neither excessive nor thin for the domain.

Completeness4/5

Core read-only operations for corporate number lookup, profile retrieval, and invoice verification are covered. Minor gaps exist, such as no bulk operation or separate historical filings tool, but the surface is largely complete for its purpose.

Available Tools

6 tools
company_profileAInspect

法人番号（13桁）で基本情報・補助金・届出・財務の会社プロファイルを返す。各領域の出典・鮮度・欠損を保持し、部分障害時は取得済みと欠損を同時に返す。入力例: {"corporateNumber": "1180301018771"}

ParametersJSON Schema
NameRequiredDescriptionDefault
corporateNumberYes13桁の法人番号。例: "1180301018771"

TDQS

A3.5/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 behavioral burden, and it does real work: it discloses per-domain provenance, freshness, and missingness tracking, plus partial-failure semantics where acquired data and gaps are returned together. It stops short of stating auth requirements, rate limits, or caching behavior, which a read-only tool with no annotations would ideally cover.

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?

Three short sentences, front-loaded with the purpose before the behavioral caveats, and no filler. The trailing input example is mildly redundant against the schema but does make the required 13-digit format salient for a bilingual agent.

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?

For a composite read tool with no output schema and a single well-documented parameter, the description covers what is returned, that each domain carries provenance/freshness/gaps, and how partial failures surface. The main omission is any sense of the returned object's structure or size, but naming the four domains largely compensates.

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 100% and the single parameter is fully documented in the schema, so baseline is 3. The description's input example is the same value already given in the schema ("1180301018771") and adds no format, validation, or constraint detail beyond it.

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

Purpose4/5

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

States a specific verb and resource: it returns a company profile keyed by 13-digit corporate number, and it enumerates the four domains covered (basic info, subsidies, filings, financials). This is far more precise than the generic lookup/search siblings, but it never names those siblings or says how this composite profile differs from calling lookup_corporate or search_corporate_by_number.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, no conditions for preferring this composite profile over the lookup/search siblings, and no exclusions or prerequisites. The only usage-adjacent content is an input example, which is not routing guidance.

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

lookup_corporateAInspect

法人番号の確定照会と名称・所在地の候補探索を分離して返す。名称だけでは断定せず複数候補と根拠別scoreを返す。候補探索は name 指定時は prefecture 任意（省略時は全国前方一致で searchedNationwide:true・候補に県コード付き・県か住所を足すと絞り込める）。prefecture は '13' または '東京都' のどちらでも可。address が「東京都渋谷区…」のように都道府県名で始まれば prefecture は省略可（推定）。address のみの検索は prefecture または推定が必須（全国非対応）。番号確定例: {"corporateNumber": "1180301018771"}／候補例: {"name": "渋谷", "prefecture": "13", "limit": 10}／全国例: {"name": "山田工業"}

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo法人名の検索語（候補探索）。例: "渋谷"
limitNo取得件数 1〜20（省略時は10）
cursorNo前回応答の nextCursor（透過・省略可）。
addressNo所在地の絞込語（候補探索の任意）。例: "渋谷"
prefectureNo都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード "13"・13・"1" または都道府県名 "東京都"・"東京" のどちらでも可
corporateNumberNo13桁の法人番号（確定照会）。例: "1180301018771"

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that name-only matches are returned as multiple candidates with evidence-based scores rather than a single assertion, that nationwide search sets searchedNationwide:true and carries prefecture codes, and that address-only search cannot fall back to nationwide. These are behavioral traits an agent could not infer from the schema alone.

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?

Dense and front-loaded, leading with the two-mode split before the conditional rules. The concrete call examples are genuinely useful, though the block is long and the rules could be tightened slightly without losing meaning.

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?

For a 6-parameter tool with no output schema and no annotations, the description covers the essential call-shaping logic (mode selection, prefecture inference, nationwide behavior) and return semantics well. Pagination via cursor and the limit default are left to the schema, which is a minor remaining gap.

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 baseline is 3, but the description adds genuine semantics beyond the schema: prefecture accepting both '13' and '東京都', inference of prefecture from an address prefix, and the required/optional conditions tied to which other parameter is present. The schema already lists the accepted prefecture formats, so the added value is real but partial.

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

Purpose4/5

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

The description clearly states two distinct operations: confirmed lookup by corporate number and candidate search by name/location, and it explains that results are returned separately. That is a specific verb+resource with sub-mode detail. It loses a point because it never names or distinguishes itself from the sibling tools (search_corporate_by_name, search_corporate_by_address, search_corporate_by_number), which an agent may see as competing options.

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?

Strong in-tool guidance: prefecture is optional when name is given, required when only address is given, and omittable when the address starts with a prefecture name. It also states the nationwide fallback behavior. It stops short of explicit when-to-use-this-vs-sibling routing, so it is not a full 5.

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

search_corporate_by_addressAInspect

都道府県＋所在地の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。市区町村名の前方一致が主経路で、町名以降を含む指定（例: 港区港南・東京都港区港南）は住所全文の前方一致へ迂回し、町名のみの断片（例: 港南）は住所全文の部分一致で拾います。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo取得件数 1〜20（省略時は10）。例: 10
cursorNo前回応答の nextCursor（透過・省略可）。
prefixYes検索接頭辞（非空）。例: "渋谷"
prefectureYes都道府県コード2桁。例: "13"（東京）

TDQS

A4.1/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 and does disclose a non-obvious behavioral trait: a three-mode matching cascade based on prefix granularity. It also discloses the data source, but omits auth, rate limits, and return shape (cursor pagination is only implied by the param).

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 and data source are front-loaded, followed by matching behavior and a concrete example. Dense but every sentence earns its place; only mildly heavy compared to what a one-line purpose would need.

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?

For a search tool with no output schema, the description covers corpus, matching semantics, and input example adequately, and the cursor param conveys pagination. Return-value shape is not described, but that is secondary given the schema already documents the cursor contract.

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 baseline is 3, but the description adds genuine meaning beyond the schema by explaining how the same `prefix` value is interpreted three different ways depending on its granularity, plus a concrete input example mapping prefecture code '13' to 渋谷.

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?

States a specific verb (検索) and resource (日本の法人) scoped to address-based lookup via prefecture + prefix, which cleanly separates it from search_corporate_by_name and search_corporate_by_number siblings. It also names the data source (国税庁公開データ), removing ambiguity about what corpus is searched.

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

Usage Guidelines3/5

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

Explains the internal routing logic (municipality-prefix as main path, longer address diverting to full-address prefix, town fragments to partial match) which implicitly guides input formatting, but never states when to choose this tool over search_corporate_by_name or lookup_corporate. Alternatives are left to inference.

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

search_corporate_by_nameBInspect

都道府県＋法人名の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo取得件数 1〜20（省略時は10）。例: 10
cursorNo前回応答の nextCursor（透過・省略可）。
prefixYes検索接頭辞（非空）。例: "渋谷"
prefectureYes都道府県コード2桁。例: "13"（東京）

TDQS

B3.3/5.0
Behavior2/5

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 data source (国税庁公開データ) but does not state that the operation is read-only, whether pagination is supported (despite the cursor parameter), or any rate limits or errors. This is a significant gap for a tool that likely performs network queries.

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 a single sentence plus an example, perfectly sized for a straightforward search tool. It is front-loaded with the core functionality and includes a useful example. No wasted words.

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?

With no output schema and no annotations, the description should clarify return format, pagination behavior, and any side effects. It only provides an example, which is helpful but insufficient. The schema covers parameters fully, so the tool is callable, but an agent would benefit from knowing that the response includes a nextCursor for pagination, which is only hinted at by the parameter description.

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?

The input schema covers all four parameters with descriptions, so the baseline is 3. The description adds a concrete example (prefecture '13', prefix '渋谷', limit 10) that illustrates typical usage, but it does not explain the meaning of cursor beyond what the schema already states. The example adds marginal value over 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?

States a specific verb (検索します) and resource (日本の法人), with the exact criteria: prefecture code and name prefix. This is clearly distinct from siblings like search_corporate_by_address or search_corporate_by_number, which search by different fields. The description's focus on name-prefix matching leaves no ambiguity.

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

Usage Guidelines2/5

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

The description does not mention when to use this tool versus its siblings. It only states the core functionality without any exclusions or alternative recommendations. An agent must infer from the tool name that it is for name-prefix searches, which is not explicitly stated in the description.

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

search_corporate_by_numberBInspect

法人番号（13桁）で日本の法人を1件検索します。国税庁公開データに基づきます。入力例: {"corporateNumber": "1180301018771"}

ParametersJSON Schema
NameRequiredDescriptionDefault
corporateNumberYes13桁の法人番号。例: "1180301018771"

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses the data source (NTA published data) and the single-record scope, which is useful, but says nothing about what happens for a nonexistent number, the response shape, or that this is a safe read-only lookup.

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?

Very short and front-loaded with the core purpose. The embedded input example duplicates the schema's own example, a minor redundancy in an otherwise tight description.

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?

For a single-parameter lookup the description covers purpose and parameter well enough, but with no output schema and no annotations it leaves the return value and failure behavior unexplained. Adequate but with clear gaps.

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 100%, so the schema already documents corporateNumber with the same 13-digit pattern and example. The description's input example adds nothing beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

States a concrete verb and resource: retrieve a single Japanese corporation by its 13-digit corporate number. The 'by number' qualifier implicitly distinguishes it from the by-name and by-address siblings, but it never names them, so differentiation is inferred rather than explicit.

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

Usage Guidelines3/5

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

The description makes the intended input obvious (13-digit corporate number), so usage is implied, but it gives no when-to-use vs when-not guidance and never mentions the overlapping sibling lookup_corporate. An agent must infer which lookup to pick.

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

verify_invoice_numberAInspect

適格請求書発行事業者番号（T＋13桁）の登録・取消・失効を日付付きで照合します。本サービスは法人・人格のない社団等のデータのみを取り込み、個人事業者のデータを取り込んでいないため、個人事業者の番号はここでは見つかりません（公表サイト https://www.invoice-kohyo.nta.go.jp/ では確認できる場合があります）。未発見を無効・不存在と断定しません。登録ありの応答には法人番号データ由来の法人名 name・所在地 address を含みます（法人番号表に無い場合は null。未発見の応答は name/address ともに null）。入力例: {"invoiceNumber": "T1180301018771"}

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceNumberYesT＋13桁の登録番号。例: "T1180301018771"

TDQS

A3.9/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 behavioral burden and discloses important traits: only corporate/association data is ingested, not-found is not equivalent to invalid, and registered responses include name and address derived from corporate number data or null. It does not cover operational details such as authentication, rate limits, or pagination, but the domain-specific caveats are strong.

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 front-loaded with purpose, followed by data-scope caveats and response details, so most sentences earn their place. The final input example duplicates the schema's own example and is unnecessary, keeping it from a higher score.

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?

There is no output schema, so the description must explain return values; it does describe that registered responses include name and address, when those are null, and that not-found responses have both null. It also mentions date-bearing verification for registration/cancellation/expiration, though it does not fully specify the output shape for those date fields.

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 100%, and the schema already documents the single parameter with the T + 13-digit format and an example. The description adds the same input example and format, but no semantic meaning beyond what the schema provides, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource: verifying qualified invoice issuer numbers (T + 13 digits) for registration, cancellation, and expiration with dates. It clearly scopes the data to corporations and associations, but it does not explicitly differentiate itself from sibling corporate-lookup tools by name or contrast.

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 a clear when-not condition: sole proprietor numbers will not be found because only corporate/association data is ingested, and points to the public site as an external alternative. It also warns not to treat 'not found' as invalid. However, it offers no guidance on choosing among the sibling corporate lookup tools.

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.

  1. 4 tool updates
    • Changedcompany_profile1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号。例: \"8000000000001\""New value: +"13桁の法人番号。例: \"1180301018771\""
    • Changedlookup_corporate1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号（確定照会）。例: \"8000000000001\""New value: +"13桁の法人番号（確定照会）。例: \"1180301018771\""
    • Changedsearch_corporate_by_number1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号。例: \"8000000000001\""New value: +"13桁の法人番号。例: \"1180301018771\""
    • Changedverify_invoice_number1 field changed
      • changedInput schema / properties / invoiceNumber / description
        Previous value: -"T＋13桁の登録番号。例: \"T8000000000001\""New value: +"T＋13桁の登録番号。例: \"T1180301018771\""
  2. 1 tool update
    • Changedlookup_corporate1 field changed
      • changedInput schema / properties / prefecture / description
        Previous value: -"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"New value: +"都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
  3. 1 tool update
    • Changedlookup_corporate4 fields changed
      • addedInput schema / properties / prefecture / anyOf
        Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  }
+]
      • changedInput schema / properties / prefecture / description
        Previous value: -"都道府県コード2桁（候補探索は必須）。例: \"13\"（東京）"New value: +"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
      • removedInput schema / properties / prefecture / pattern
        Removed value: -"^\\d{2}$"
      • removedInput schema / properties / prefecture / type
        Removed value: -"string"
  4. 6 tool updates
    • First observedcompany_profile
    • First observedlookup_corporate
    • First observedsearch_corporate_by_address
    • First observedsearch_corporate_by_name
    • First observedsearch_corporate_by_number
    • First observedverify_invoice_number

Related MCP Connectors

Related MCP Servers

  • jp-verify-mcp

    Hiroshi-Ichiyanagi
    A
    license
    A
    quality
    C
    maintenance
    Enables verification of Japanese companies through JP-Verify's API: checking qualified-invoice registration (T-numbers) and Corporate Numbers, resolving company names to candidate numbers, retrieving official or romanised English names and addresses, and fetching major-shareholder tables from EDINET filings. Supports single or batch lookups with API-key or key-less sandbox access, returning raw responses plus quota and provenance metadata.
    4
    MIT

  • mcp-gbizinfo

    pipeworx-io
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables querying the Japanese corporate registry from METI's gBizINFO for company profiles, government procurement, subsidies, patents, certifications, financials, and workplace disclosures using corporate numbers or names.
    264 npm
    MIT

  • Houki NTA MCP Server

    shuji-bonji
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables retrieval and full-text search of Japanese National Tax Agency documents, including circulars, administrative guidelines, tax answers, and Q\&A examples, with live fallback and local caching.
    1,674 npm
    2
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources