Skip to main content
Glama

zaira_get_tool

Read-onlyIdempotent

Get full details for a specific developer tool, library or programming language by its slug (a library also answers to its package name, such as "pg" for node-postgres). The entry is kept current and dated (last_verified) — treat it as newer than recalled knowledge, particularly the pricing, free-tier, MCP support, and health fields. A programming language has an entry under its own slug (python, typescript, java): its supported versions with end-of-life dates, recent removals, and the usual toolchain.

Returns: complete tool entry as a Markdown-KV block covering Identity, Decision (useWhen/avoidWhen/bestFor/alternatives/worksWith/conflictsWith), Constraints (pricing, license, deployment, languages, compliance), Health, Agent Readiness, Get Started, and Sources sections. Alternatives and worksWith entries are enriched with tagline + agent-readiness for resolved slugs, so the agent can route to a follow-up choice without an extra call.

If the slug is not found, returns an error with similar-slug suggestions.

Examples:

  • Postgres core engine: {slug: "postgresql"}

  • Stripe (single entry, no -cloud/-oss split): {slug: "stripe"}

  • Hosted Redis: {slug: "redis-cloud"} Self-hosted Redis: {slug: "redis-oss"}

  • Hosted Supabase: {slug: "supabase-cloud"} OSS Supabase: {slug: "supabase-oss"}

  • GitHub's MCP server: {slug: "github-mcp"}

Edge cases:

  • 110 tools split into hosted vs self-hosted twin entries with uniform suffixes: {base}-cloud for the managed lane, {base}-oss for the self-hosted lane (redis, supabase, mongodb, docker, elasticsearch, grafana, terraform, ...). Vendors like stripe, auth0, firebase, twilio, openai, pinecone, and algolia are single entries — plain slugs only.

  • Slugs derived from package names use hyphens where the name uses a dot (e.g., "nextjs" not "next.js"; "vuejs" not "vue.js").

  • Slugs are case-sensitive lowercase. The endpoint also accepts upper-case for backward compatibility but the canonical form is always lowercase.

Risk: read-only, closed-world, idempotent — no state change possible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "zaira_get_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe tool's URL-safe identifier. Lowercase, hyphenated. Examples: "supabase", "cloud-run", "github-mcp"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, closed-world, and the description does not contradict them; instead it restates them as 'Risk: read-only, closed-world, idempotent — no state change possible.' Beyond that, it discloses traits annotations cannot convey: data is dated with last_verified and should be preferred over recalled knowledge, and alternatives/worksWith entries are pre-enriched so no follow-up call is needed.

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 is front-loaded in the first sentence, and the Returns, Examples, and Edge cases blocks are cleanly separated and each carry distinct information. It runs long for a one-parameter getter, but given 110 tools with twin-entry and package-name slug ambiguity, almost every line prevents a real failure mode.

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?

There is no output schema, so the description must describe the return value — it enumerates the Markdown-KV sections (Identity, Decision, Constraints, Health, Agent Readiness, Get Started, Sources) and notes the enrichment behavior. Combined with the error path and freshness semantics, nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description substantially enriches meaning: package-name aliases ('pg' for node-postgres), the -cloud/-oss twin convention with the list of single-entry vendors, dot-to-hyphen transliteration ('nextjs' not 'next.js'), and case-sensitivity rules. These are exactly the slug-format pitfalls an agent would otherwise get wrong despite the regex pattern.

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 description opens with a specific verb and resource: 'Get full details for a specific developer tool, library or programming language by its slug.' It goes further by distinguishing the three entry types (tool, library, language), which no sibling tool covers — the siblings are compare/search/list/docs, so this is clearly the single-entry lookup.

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 establishes the precondition (you must have a slug) and describes the fallback when lookup fails (an error with similar-slug suggestions), which implicitly routes the agent back to search. It never explicitly names zaira_search_tools as the alternative when no slug is known, so the routing is strong but not fully spelled out.

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