Skip to main content
Glama
Sign In

IsraBase

by com.israbase
OverviewDiscussionsAdmin

Search the registry

search_companies
Read-onlyIdempotent

Search Israeli companies, nonprofits or partnerships by name or number. חיפוש חברות, עמותות או שותפויות לפי שם או מספר. Optional city, status and segment apply to companies. segment matches the HTTP API type query: government, public, foreign or bonds. Default active_only returns visible (publicly listed) rows only. Set active_only to false to include unlisted rows. Direct get_* tools always look up by number, listed or not.

Input Schema

NameRequiredDescriptionDefault
cityNoCompany city. Hebrew name. Optional.
typeNoWhich registry. Default company.
limitNoMax 25. Default 10.
queryYesName or registration number. שם או מספר.
statusNoCompany status. Hebrew value, exact match. Optional.
segmentNoCompany segment. Same values as the HTTP type query. Optional.
active_onlyNoDefault true. true keeps visible = 1 (the public listing filter).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / city
      Added value: +{
+  "description": "Company city. Hebrew name. Optional.",
+  "maxLength": 80,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / segment
      Added value: +{
+  "description": "Company segment. Same values as the HTTP type query. Optional.",
+  "enum": [
+    "government",
+    "public",
+    "foreign",
+    "bonds"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / status
      Added value: +{
+  "description": "Company status. Hebrew value, exact match. Optional.",
+  "maxLength": 80,
+  "minLength": 1,
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and openWorld, so the bar is lower. The description still adds real context: active_only defaults to true and filters to publicly listed rows, and segment maps to the HTTP API type query. It does not describe result shape or pagination, but that is a minor gap given annotation coverage.

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?

Front-loaded with the core action and search keys, then parameter-specific notes. The segment clarification is repeated between description and schema and the bilingual duplication adds length, but both serve a real purpose and nothing is wasted outright.

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 7-parameter search tool with no output schema and full annotation coverage, the description supplies the non-obvious semantics (active_only filter, segment mapping, company-only scope). Missing is any hint about result ordering, pagination or what a hit contains, which an agent may need to chain searches correctly.

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 baseline is 3; the description earns an extra point by clarifying that segment uses the HTTP API type values (government/public/foreign/bonds) and that city/status/segment apply only to companies. It also explains the active_only semantics beyond the terse schema line.

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+resource (search companies/nonprofits/partnerships) plus the matching keys (name or number), and explicitly contrasts with the get_* siblings. An agent can distinguish it from list_companies_by_* and get_* without opening the 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?

Explicitly says direct get_* tools look up by number regardless of listing, which routes the agent away from this tool for exact lookups. Also documents the active_only toggle condition. It does not address overlap with siblings like list_companies_by_city when the city param is used, so it falls short of full when/when-not coverage.

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

All IsraBase toolsInspect
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