Skip to main content
Glama

search_companies

Read-onlyIdempotent

Search NZX-listed companies by name or ticker. Returns company list with sector, market cap.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 10)
searchNoCompany name or ticker to search for (e.g. "air new zealand" or "AIR")
sectorNoFilter by sector (e.g. "Energy", "Healthcare")

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool payload. Null when the call did not produce one — read meta.availability_status to find out why, and do not treat null as zero, empty or "none found".
metaYes
toolYesTool that produced this result.
schema_versionYesEnvelope contract version. Bumps only on a breaking shape change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "description": "The tool payload. Null when the call did not produce one — read meta.availability_status to find out why, and do not treat null as zero, empty or \"none found\"."
      +    },
      +    "meta": {
      +      "additionalProperties": true,
      +      "properties": {
      +        "availability_status": {
      +          "description": "ok: complete payload. truncated: payload exceeded the transport cap and was cut. parse_failed: payload is text this server could not parse as JSON. error: the tool raised.",
      +          "enum": [
      +            "ok",
      +            "truncated",
      +            "parse_failed",
      +            "error"
      +          ],
      +          "type": "string"
      +        },
      +        "encoding": {
      +          "description": "toon = pipe-delimited tabular encoding; header row names the columns.",
      +          "enum": [
      +            "json",
      +            "toon"
      +          ],
      +          "type": "string"
      +        },
      +        "provenance": {
      +          "description": "Whether the figures can cite a source document. \"undeclared\" means no claim has been made for this endpoint yet — it is not a claim that the data is unsourced.",
      +          "enum": [
      +            "direct",
      +            "label",
      +            "reachable",
      +            "none",
      +            "undeclared"
      +          ],
      +          "type": "string"
      +        },
      +        "retrieved_at": {
      +          "description": "When this platform produced the answer — NOT the as-at date of the data.",
      +          "format": "date-time",
      +          "type": "string"
      +        },
      +        "warnings": {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "required": [
      +        "retrieved_at",
      +        "availability_status",
      +        "provenance"
      +      ],
      +      "type": "object"
      +    },
      +    "schema_version": {
      +      "description": "Envelope contract version. Bumps only on a breaking shape change.",
      +      "type": "string"
      +    },
      +    "tool": {
      +      "description": "Tool that produced this result.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "schema_version",
      +    "tool",
      +    "data",
      +    "meta"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only the return shape (a company list with sector and market cap), which duplicates the output schema rather than adding behavior like truncation or ranking.

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?

Two front-loaded sentences with zero filler: purpose first, return shape second. The second sentence is slightly redundant given the output schema, but it costs little.

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?

All params are optional, so an agent needs to know what an empty call does (list all companies? error?), and the description never says whether search is required. With annotations and an output schema already carrying most weight, the remaining gap is the no-argument behavior.

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 coverage is 100%, so the schema already documents search, sector, and limit including examples. The description echoes the name/ticker search ('air new zealand' or 'AIR') but adds no meaning 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 specific verb and resource (search NZX-listed companies by name or ticker) plus what comes back (sector, market cap). It doesn't identify how it differs from close siblings like screen_stocks or get_company_detail, so an agent must infer the boundary.

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?

No when-to-use or when-not-to-use guidance and no mention of alternatives such as screen_stocks (screening) or get_company_detail (full detail for one company). The name-based lookup use case is only implied by the description's wording.

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.