Zambo AI Tools

Server Details

10+ AI native tools, free

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 12:30
Transport: Streamable HTTP
URL

Available Tools

10 tools

capability_searchAInspect

Search across all 100+ Zambo Stack tools via one MCP connection to find what fits your use case. Returns up to 8 relevant products with relevance scores, descriptions, taglines, and callable API endpoints. Use this before zambo_universal when you know exactly which product you want. When to use: call capability_search when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`q`	No	Search keyword or phrase. Also accepts the natural aliases query, keyword, or search. Example: 'code audit', 'prompt injection defense', 'wallet scoring', 'lead generation', 'trust verification'
`query`	No	Alias for q. Use q when possible.
`search`	No	Natural-language alias for q.
`keyword`	No	Natural-language alias for q.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No
`tools`	No
`matched`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states search scope (all 100+ tools), result count limit (up to 8), and output contents (relevance scores, descriptions, taglines, callable API endpoints). It does not mention side effects, but as a search tool this is adequate and nothing contradicts the annotations.

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 and output details, then moves into usage guidance. It includes some redundancy — 'When to use: call capability_search when the user's request matches this capability' is a tautology — but the overall structure is clear and compact. Every major section earns its place.

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?

The tool is simple (one primary semantic parameter with aliases) and an output schema exists, so the description doesn't need to explain return values in detail. It covers scope, output, usage boundaries, and an alternative. The only minor gap is a lack of explicit read-only declaration, but that's implied by the search behavior and the presence of output schema.

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 already covers all 4 parameters with 100% description coverage, including aliases and examples. The description adds no new parameter-specific meaning beyond what the schema provides, so a baseline of 3 is appropriate given the schema's thoroughness.

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: 'Search across all 100+ Zambo Stack tools', which clearly states the tool's scope and action. It also differentiates from the sibling zambo_universal by explaining it's for finding tool fits and returning callable API endpoints. This makes the purpose unmistakable.

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

Usage Guidelines5/5

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

Provides explicit 'When to use' and 'When not to use' conditions, including a named alternative (zambo_universal) and a clear sequencing rule ('Use this before zambo_universal'). It also lists exclusions such as unrelated work, missing required inputs, and safer read-only routes. This is thorough and actionable guidance.

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

credithuntBInspect

Zambo Stack — Live, verified index of every AI and cloud startup credit program available right now. 29+ active programs including AWS Activate, Google Cloud, Azure, OpenAI, Anthropic, Vercel, Supabase, Modal, Groq, Replicate, and more. Verified daily — dead links auto-removed. Pass your tech stack to get matched recommendations. Free, no auth. When to use: call credithunt when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`stack`	No	Your tech stack for matched recommendations. Example: ["openai","vercel","aws"]. Leave empty to get all programs.
`stage`	No	Your stage: solo (1 person), early (2–10), growth (10+). Default: solo.
`min_value`	No	Minimum credit value in USD to filter by (optional). Example: 5000

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No
`matched`	No
`programs`	No

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It adds useful context: 'Live, verified index', 'Verified daily — dead links auto-removed', and 'Free, no auth'. However, it never explicitly states that the tool is read-only or describes side effects, rate limits, or response behavior beyond 'matched recommendations'.

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

Conciseness3/5

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

The purpose is front-loaded and the list of example programs is illustrative, but the description overstays a bit: the long program list is redundant after '29+ active programs', and the 'When to use' sentence is close to tautological. It is not poorly structured, but not every sentence earns its place.

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?

Given the simple optional-parameter shape, full schema coverage, and presence of an output schema, the description is reasonably complete for an agent to invoke the tool. The main gap is weak usage guidance, but the schema and output schema cover the operational details.

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 schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds only 'Pass your tech stack' but does not elaborate on stage or min_value, so it does not meaningfully extend what the schema already provides.

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 identifies the resource (AI and cloud startup credit programs) and the action ('get matched recommendations'), and it gives concrete examples of included programs. It does not explicitly distinguish credithunt from sibling tools like zambo_compare or zambo_live, so it stops short of a 5.

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 includes 'When to use' and 'When not to use' sections, which is useful, but the guidance is generic ('when the user's request matches this capability') and never names alternatives or concrete selection criteria. The note about 'missing required inputs' is also misleading since all parameters are optional.

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

leadsignalAInspect

Zambo Stack — AI lead generation for contractors and local service businesses. Provide a trade type and city — get 5 qualified leads with contact info in under 60 seconds. Supports 24 trades and any US city. 3 free searches per day per IP. No auth. When to use: call leadsignal when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description	Default
`city`	Yes	City and optional state. Example: 'Chicago', 'Denver CO', 'Austin Texas'
`trade`	Yes	The trade or service type. Example: 'plumber', 'HVAC', 'electrician', 'roofer', 'general contractor'

Output Schema

ParametersJSON Schema

Name	Required	Description
`city`	No
`count`	No
`leads`	No
`trade`	No

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 behavioral burden and does so well: it discloses no auth, a rate limit of 3 free searches per day per IP, a performance expectation of under 60 seconds, and the output contents. These are exactly the behavioral traits an agent needs beyond the schema.

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 capability is front-loaded and the description remains compact despite including operational context. The 'When to use' sentence is somewhat tautological, but the overall structure is scannable and free of excessive detail.

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 simple 2-parameter tool with an output schema, the description covers inputs, output contents, quota, auth, and latency. It omits rate-limit failure behavior and does not clarify the relationship with leadsignal_generate, but neither is required for basic correct invocation.

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. The description adds value by constraining trade to 24 supported trades and city to any US city, going beyond the schema's examples. It does not enumerate the full list of supported trades, but the schema already provides representative examples.

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 identifies the capability: AI lead generation for contractors/local businesses, taking a trade and city and returning 5 qualified leads with contact info. It is specific and action-oriented, but it does not distinguish itself from the closely named sibling leadsignal_generate, so sibling differentiation is incomplete.

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?

The description includes explicit when-to-use and when-not-to-use guidance, including avoiding missing required inputs, unrelated requests, and cases where a safer read-only route is more appropriate. It does not name concrete alternative tools, but the stated conditions are clear and usable.

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

live_priceAInspect

Real-time cryptocurrency price lookup for any coin — BTC, ETH, SOL, DOGE, BNB, XRP, MATIC, AVAX, ADA, LINK, and 100+ others. Returns live USD price, 24h % change, and market cap directly from CoinGecko. Use for ANY 'what is X price', 'X price now', 'how much is X', or 'X USD' query. Do NOT use market_pulse for specific coin prices — use this tool. When to use: call live_price when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Coin ticker or name — BTC, ETH, SOL, DOGE, BNB, XRP, MATIC, AVAX, ADA, LINK, DOT, UNI, ATOM, NEAR, APT, OP, ARB, SUI, PEPE, WIF, BONK, TON, TRX, LTC, SHIB. Case-insensitive.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses the data source (CoinGecko) and return content (live USD price, 24h % change, market cap), which implies a read-only lookup, but it does not explicitly state read-only semantics, rate limits, or potential failure behavior. Acceptable but not comprehensive.

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

Conciseness3/5

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

The core information is front-loaded in the first two sentences, but the later "When to use: call live_price when the user's request matches this capability" is purely tautological, and the "When not to use" clause is generic filler. The useful content could be delivered in half the length.

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 simple single-parameter read tool with an output schema, the description covers the data source, return fields, and representative input patterns. Minor gaps remain—no explicit note on timeliness/latency or rate limits—but overall an agent can select and invoke this tool 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 adds semantic breadth with "100+ others," signaling that symbol accepts any coin beyond the enumerated list, and reinforces that both ticker or name forms work. This enriches meaning beyond the schema's example list.

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?

Description states a clear verb+resource: "Real-time cryptocurrency price lookup for any coin" and enumerates specific symbols. It explicitly distinguishes itself from sibling market_pulse: "Do NOT use market_pulse for specific coin prices — use this tool." No ambiguity about what the tool does.

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?

Gives concrete trigger patterns: "Use for ANY 'what is X price', 'X price now', 'how much is X', or 'X USD' query" and explicitly routes away from market_pulse. The generic "when not to use" line is somewhat tautological but the specific exclusions and named alternative provide solid guidance.

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

prompt_shieldAInspect

Zambo Stack — Detect prompt injection, jailbreaks, and policy bypass attempts before they reach your AI model. Two-phase analysis: instant pattern library scan (12 attack vectors) + Groq semantic analysis. Returns injection_risk 0–100, recommendation safe/review/block, and a safe rewritten version when possible. 50 free/day. Best for: 'validate user input before LLM call', 'detect jailbreak attempts', 'is this prompt safe to send to GPT?'. When to use: call prompt_shield when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`mode`	No	'fast' = pattern scan only (default), 'deep' = pattern + Groq semantic analysis
`email`	No	Zambo Pass email for unlimited calls (optional)
`prompt`	Yes	The user input or prompt to validate for injection/jailbreak (max 16K chars)
`system`	No	Your system prompt — also scanned for prompt leak attempts (optional)
`context`	No	Describe your app for better contextual analysis (optional)

Output Schema

ParametersJSON Schema

Name	Required	Description
`safe`	No
`threats`	No
`sanitized`	No

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations at all, the description carries the full disclosure burden and succeeds: it explains the two-phase analysis (pattern scan + Groq semantic analysis), the numeric risk output, the safe/review/block recommendation, the safe rewritten version, and the 50-free-per-day rate limit. It clearly implies a read-only safety-check operation, so no destructive side effects need to be disclosed.

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 the core purpose and behavioral summary, then flows into quota and usage guidance. The main deduction is for the tautological 'When to use' sentence and generic 'unrelated work' exclusion, which add little beyond the 'Best for' examples.

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?

For a five-parameter tool with 100% schema coverage, an output schema, and detailed behavioral text, nothing critical is missing. It explains what the tool returns, how many calls are free, what inputs matter, and when not to use it; the output schema covers the return structure, so the description need not repeat it.

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 all five parameters. The description adds no extra parameter-level meaning beyond what the schema provides, giving the baseline 3; it does not repeat or improve on the mode/email/system/context documentation.

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 action ('Detect prompt injection, jailbreaks, and policy bypass attempts') and names the exact resource guarded ('your AI model'). The 'Best for' examples ('validate user input before LLM call', 'detect jailbreak attempts', 'is this prompt safe to send to GPT?') make the purpose unmistakable and specialized enough to set it apart from the many security/audit siblings.

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 provides concrete 'Best for' examples and explicit When to use/When not to use sections, including the exclusion of unrelated work and the preference for a safer read-only route when appropriate. However, it never names a specific sibling tool as the alternative, and the 'when the user's request matches this capability' clause is somewhat tautological.

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

proof_certifyAInspect

Cryptographically certify any AI-generated content with a permanent SHA-256 provenance certificate — tamper-proof, publicly verifiable forever. Perfect for: certifying AI outputs before sharing, audit trails for agent decisions, proving timestamp and authorship of any content. Returns cert_id, permanent verify_url (zambo.dev/proof), and SHA-256 hash. AGENT USE: Call after any important tool result to create a receipt then share the verify_url — any human or agent can verify it at zambo.dev/proof permanently. Free: 5 certs/day. Zambo Pass: unlimited. When to use: call proof_certify when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`email`	No	Optional Zambo Pass email for unlimited certs
`label`	No	Human-readable label (e.g. 'ZAMBOT Spark', 'Strategy Plan', 'Agent Decision')
`content`	Yes	The content to certify — AI output, decision, plan, analysis, or any text

Output Schema

ParametersJSON Schema

Name	Required	Description
`cert_id`	No
`verify_url`	No
`sha256_hash`	No

TDQS

A3.8/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full transparency burden. It discloses permanence ('permanent... publicly verifiable forever'), the return payload (cert_id, verify_url, hash), and the quota model ('Free: 5 certs/day. Zambo Pass: unlimited'). It does not address privacy implications of permanent public verification or failure behavior on quota exhaustion, but major behavioral traits are covered.

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

Conciseness3/5

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

The description contains useful behavioral information but is padded with promotional phrasing ('Perfect for:', 'tamper-proof') and a tautological usage line ('call proof_certify when the user's request matches this capability'). The key purpose is front-loaded in the first sentence, but the rest could be tightened 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 3-parameter tool with an output schema, the description is fairly complete: it covers use case, trigger, return values, verification URL, and quotas. It stops short of concretely explaining what a 'safer read-only route' would be and does not name the verification sibling, leaving some ambiguity for tool selection. Most information needed to call it correctly is present.

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 already documents all three parameters with 100% coverage. The description adds little beyond restating that content is certified; for example, the schema already says content is 'AI output, decision, plan, analysis, or any text.' The only small addition is connecting email to the free-tier/unlimited distinction. This is a baseline score.

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 a specific verb-resource pair: 'Cryptographically certify any AI-generated content with a permanent SHA-256 provenance certificate.' It also names outputs (cert_id, verify_url, SHA-256 hash) and use cases. However, it does not explicitly distinguish itself from sibling verification tools like zambot_verify, so differentiation is left to inference.

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?

Provides explicit usage guidance: 'Call after any important tool result to create a receipt' and a 'When not to use' section listing exclusions such as unrelated work, missing required inputs, and when a safer read-only route is more appropriate. It gives clear context and exclusions but does not name a specific alternative tool, stopping short of a top score.

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

provibe_auditBInspect

AI code audit for any public GitHub repository. Returns Provibe Score (0–100), security vulnerability list, dead code map, and an actionable execution plan. Free teaser gives score + top 3 issues. Full audit: $49 one-time OR included in Zambo Pass ($49/mo — 5 audits/month, $245 value). Pass Zambo Pass email in request for full audit. No auth required for teaser. When to use: call provibe_audit when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`email`	No	Zambo Pass email for full audit (optional — without it you get the free teaser: score + top 3 issues). Get pass: https://zambo.dev/#zambo-pass
`repo_url`	Yes	Public GitHub repository URL. Example: https://github.com/owner/my-saas
`vibe_context`	No	Optional context: language, framework, specific concerns, or what the project does

Output Schema

ParametersJSON Schema

Name	Required	Description
`dead_code`	No
`provibe_score`	No
`execution_plan`	No
`vulnerabilities`	No

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses the free teaser behavior, the paid full-audit requirement, that no auth is needed for the teaser, and that a Zambo Pass email is required for the full audit. It does not discuss failure modes or side effects, but the audit is inherently read-only and the main behavioral branch is well explained.

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

Conciseness3/5

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

The first sentence is well front-loaded with purpose and outputs, and the teaser/auth details follow logically. However, the 'When to use' line is a filler tautology, and the '5 audits/month, $245 value' pricing math is marketing noise that does not help an agent invoke the tool.

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?

The description covers return content, the teaser/full split, auth posture, and all parameter semantics; the output schema covers result shape. It does not mention error behavior for invalid/non-public repos or what happens if an invalid email is provided, but those are secondary to making a correct first call.

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 baseline is 3. The description largely restates what the email parameter already explains (teaser without it, full audit with it) and adds the pricing construct around it. It adds no new syntactic or semantic detail about repo_url or vibe_context beyond the schema.

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 opens with a concrete verb/resource — 'AI code audit for any public GitHub repository' — and lists specific deliverables (Provibe Score 0–100, security vulnerabilities, dead code map, execution plan). It is clear in purpose but does not explicitly distinguish itself from sibling audit/review tools like code_review or ghost_audit_report.

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?

It includes a 'When to use' block, but the guidance is tautological ('when the user's request matches this capability') and the exclusions are generic ('unrelated work', 'missing required inputs', 'safer read-only route'). No sibling alternatives are named, so an agent gets no concrete decision rule for choosing this tool over code_review or ghost_audit_report. The teaser-vs-full-audit conditional is useful, but it does not compensate for the lack of real alternative guidance.

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

zambo_liveAInspect

Live session report — see exactly what tools have been called, when, how fast, and what's active right now. Returns a full chronological activity log across Zambo MCP and Axis MCP for this server session. Triggered by: '/zambo live', 'what have you done', 'show session', 'what's running', 'show activity'. Shows: tool call history in order, timing per call, which memory layer was used, session stats, top tools called, and links to the real-time web dashboard at zambo.dev/live. When to use: call zambo_live when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description	Default
`layer`	No	Filter by MCP layer — zambo (100+ tools), axis (11 tools), or all. Default: all
`limit`	No	How many recent calls to show (default: 20, max: 50)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	No

TDQS

A3.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full disclosure burden and it handles this well. It discloses the session scope ('for this server session'), lists the returned data (chronological history, timing per call, memory layer, session stats, top tools) and links a real-time web dashboard, clearly implying a read-only observation tool. It omits an explicit side-effect-free statement and auth needs, but for a no-required-input reporting tool the behavioral profile is largely evident.

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

Conciseness3/5

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

Front-loaded with the core purpose ('Live session report') before any trigger list, which is good. But the body is padded with a long trigger-phrase enumeration and a when-to-use section that restates the purpose circularly, diluting signal density with low-value sentences. Organized into labeled sections, yet not every sentence earns its place.

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 low-complexity read-only reporting tool with a 100%-covered schema, an output schema, and zero required params, the description covers the essentials: scope across both MCP layers, contents of the report, session binding, and a dashboard reference for real-time views. The weak when-to-use guidance is the main gap, but it is minor for a no-input discovery tool.

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% — both layer (enum: zambo/axis/all) and limit (default 20, max 50) are fully documented in the input schema. The description adds marginal parameter-level value; 'across Zambo MCP and Axis MCP' loosely mirrors the layer enum but adds no syntax or format detail. Baseline 3 is correct when the schema does the heavy lifting.

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: 'Live session report — see exactly what tools have been called, when, how fast, and what's active right now. Returns a full chronological activity log across Zambo MCP and Axis MCP.' The core function as an activity/reporting tool is explicit. However, it does not distinguish itself from the many overlapping zambo_* siblings (zambo_session, zambo_pulse, zambo_watch, zambo_check), so an agent would still need to inspect other schemas to pick the right one.

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?

Provides concrete trigger phrases ('/zambo live', 'what have you done', 'show session', 'what's running', 'show activity') that help an agent recognize when to fire. But the explicit 'When to use' clause is circular ('call zambo_live when the user's request matches this capability'), and the 'When not to use' guidance ('unrelated work, missing required inputs') is generic boilerplate that names no alternative tools. No explicit sibling routing.

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

zambot_sparkAInspect

Generate a cross-domain strategy insight for any goal. ZAMBOT synthesizes available tool context and returns a Spark with a hash-backed record. A proof hash can help identify the returned record; it does not independently verify the accuracy or outcome of the insight. Each Spark includes a shareable URL (zambo.dev/spark/). 3 free sparks per 24h per IP. For higher limits use day_pass_activate or Zambo Pass. When to use: call zambot_spark when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`goal`	Yes	Your goal or strategic challenge (10–2000 chars). Example: 'Get my SaaS from 0 to 100 paying users in 60 days'
`email`	No	Zambo Pass email for 50 sparks/month, no x402 gate (optional — free tier = 3/day). Get pass: https://zambo.dev/#zambo-pass
`context`	No	Additional context about your situation (optional)
`current_plan`	No	Your current approach or what you've already tried (optional)

Output Schema

ParametersJSON Schema

Name	Required	Description
`spark`	No
`domain`	No
`spark_url`	No
`proof_hash`	No

TDQS

A3.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It credibly discloses rate limits (3 free sparks per 24h per IP), the limitations of the proof hash (does not independently verify accuracy/outcome), and the shareable URL format. This goes well beyond a generic 'generate insight' claim and sets accurate expectations about the tool's guarantees and restrictions.

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 structured with a clear opening purpose, followed by behavioral caveats, rate limits, and usage conditions. Each sentence adds information; the 'When to use' section is slightly redundant but harmless. It is longer than average yet earns its length through useful caveats and limits.

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?

The description covers the core capability, rate limits, upgrade path, proof-hash limitations, shareable URL, and exclusions. An output schema exists, so return details need not be duplicated. The main gap is a lack of differentiation from sibling zambo tools, but for an agent deciding whether to invoke this capability, the provided context is largely sufficient.

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 all four parameters thoroughly. The description adds no new parameter-specific meaning beyond echoing the free-tier vs. Zambo Pass distinction already present in the email parameter description. Baseline 3 is appropriate since the schema handles the semantic load.

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 opens with a specific action and object: 'Generate a cross-domain strategy insight for any goal.' It also names the return artifact ('Spark') and provides an example goal in the schema. It doesn't explicitly contrast with siblings like zambo_universal or zambo_live, but the 'cross-domain strategy insight' phrasing gives a reasonably distinct identity.

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 includes explicit 'When to use' and 'When not to use' sections, which is more than many tools. However, the positive guidance is tautological ('when the user's request matches this capability') and no specific sibling alternative is named. The rate-limit note about day_pass_activate is useful routing context, but general guidance like 'safer read-only route' is vague.

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

zambo_universalAInspect

Universal Zambo Stack entry point. Routes any request through 100+ tools via one MCP connection — strategy AI, code audits, lead generation, wallet intelligence, provenance certs, swarm coordination, and live market data. Free, no API key, no signup. 20 calls/tool/day on free tier. IMPORTANT: When a user asks for an actionable task, call this tool immediately and do the work. Do not respond with a catalog, setup lecture, or generic advice first. Return the concrete result, name the capability used, and give one clear next step. Zambo works with the host AI, not instead of it: keep the user's goal and constraints organized, use the returned result as the next working step, verify completion, and never claim a task is done when a tool is blocked or only suggested a route. Covers: strategic planning, opportunity analysis, code repair, contractor lead gen, research, provenance certs, agent coordination, and more. For agent coordination, multi-agent workflows, and cross-layer execution, see axis_mcp_access. Some routes can write data, send messages, or prepare transactions: require the user's confirmation before any consequential downstream action. When to use: call zambo_universal when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Collaboration mode. execute routes and performs the request; continue uses the current session trail; verify checks whether the current session has completed a request. Default: execute.
`need`	Yes	Natural language description of what you need. Any length. Also accepts: message, query, prompt, input, goal, text. Example: 'How do I protect my AI agent from prompt injection?'
`email`	No	Optional email, only with the user's consent. Namespaces Pass access and a compact working trail so the same user can continue across AI clients without restarting.
`format`	No	Response format. Default: json.
`context`	No	Optional extra context. Supported keys: repo_url, goal, trade, city, wallet, domain. Example: { "repo_url": "https://github.com/owner/repo" }
`session_id`	No	Alias for _session_id. Use one stable ID for the whole conversation so Zambo and the host AI do not repeat completed steps.
`_session_id`	No	Stable ID generated by the host AI once per conversation and reused on every Zambo call. Enables a shared working trail across multi-step tasks.
`session_code`	No	Optional ZAMBO-XXXX handoff code from Telegram /export. Loads that saved conversation into this request so another AI can continue immediately.

Output Schema

ParametersJSON Schema

Name	Required	Description
`response`	No
`routed_to`	No
`tools_invoked`	No

TDQS

A4.5/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 meets it: it discloses the write-capable nature of some routes, requires user confirmation before consequential actions, mentions rate limits, and explains the expected collaboration behavior. It also warns against claiming completion when a tool is blocked.

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

Conciseness3/5

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

The description is front-loaded with the main purpose, but it is long and contains redundancy: 'Covers' largely repeats the opening list, and 'When to use: call zambo_universal when the user's request matches this capability' is tautological. The agent-behavior paragraph is useful but could be tightened.

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?

Given the tool's broad scope, the description provides enough context: what it does, when to avoid it, which sibling to use for coordination, safety requirements for write routes, rate limits, and session/trail expectations. The output schema and fully documented parameters cover return values and inputs.

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 all 8 parameters thoroughly. The description adds some behavioral context around the request, such as calling it immediately for actionable tasks, but it does not add meaning to specific parameters like mode, context, or session_id.

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 concrete role: 'Universal Zambo Stack entry point' that 'Routes any request through 100+ tools via one MCP connection.' It names specific capability areas and differentiates itself from sibling axis_mcp_access for agent coordination. An agent can clearly tell this is the umbrella router rather than a single-purpose sibling.

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

Usage Guidelines5/5

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

The description gives explicit 'When to use' and 'When not to use' guidance, including not calling for unrelated work, missing inputs, or when a safer read-only route exists. It also directs agent-coordination requests to axis_mcp_access, giving a concrete alternative.

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. Dates show when Glama detected each change.

1 tool updateSep 5, 2026

Changedcapability_search4 fields changed

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "q"
+    ]
+  },
+  {
+    "required": [
+      "query"
+    ]
+  },
+  {
+    "required": [
+      "keyword"
+    ]
+  },
+  {
+    "required": [
+      "search"
+    ]
+  }
+]

addedInput schema / properties / keyword

Added value: +{
+  "description": "Natural-language alias for q.",
+  "type": "string"
+}

addedInput schema / properties / search

Added value: +{
+  "description": "Natural-language alias for q.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[]
```

118 tool updatesSep 5, 2026
- Removedagent_brief
- Removedagent_hire
- Removedagent_identity
- Removedaxis_agent_onboard
- Removedaxis_agent_wire
- Removedaxis_chain_proof
- Removedaxis_cross_search
- Removedaxis_drift_monitor
- Removedaxis_mcp_access
- Removedaxis_memory_handoff
- Removedaxis_outcome_submit
- Removedaxis_reputation_check
- Removedaxis_spark_to_swarm
- Removedaxis_swarm_pattern
- Removedaxis_tool_dispatch
- Removedbasehawk_score
- Removedbill_audit
- Removedbounty_scan
- Removedbuilder_pass_check
- Removedcapability_rent
- Removedcode_review
- Removedcontent_distribute
- Removedcontract_scan
- Removedday_pass_activate
- Removeddoc_intel
- Removedemail_write
- Removedfind_agent
- Removedfridge_forge
- Removedghost_audit_report
- Removedghost_audit_site
- Removedghost_audit_status
- Removedgif_animate
- Removedgit_changelog
- Removedhitl_check
- Removedhitl_submit
- Removedimage_analyze
- Removedimage_generate
- Removedleadsignal_generate
- Removedmarket_pulse
- Removedmcp_extend
- Removedmcp_install_guide
- Removedmeal_plan
- Removedmeme_forge
- Removedmodel_oracle
- Removedmonad_city
- Removedmonad_pulse
- Removedpartner_register
- Removedpartner_stats
- Removedpdf_extract
- Removedpresence_act
- Removedpresence_extract
- Removedpresence_navigate
- Removedpresence_post
- Removedpresence_reply
- Removedpresence_screenshot
- Removedpresence_session_attach
- Removedpresence_session_create
- Removedpresence_session_kill
- Removedpresence_session_list
- Removedprompt_lab
- Removedqr_generate
- Removedregex_build
- Removedreliability_score
- Removedresume_boost
- Removedsalary_script
- Removedsignal_lookup
- Removedsignal_register
- Removedsql_from_english
- Removedstack_architect
- Removedstructlock
- Removedsubstrate_breakthroughs
- Removedsubstrate_engine
- Removedthread_craft
- Removedtokendiet_analyze
- Removedtokendiet_cache
- Removedtrading_journal
- Removedtrading_leaderboard
- Removedtrading_propose
- Removedtrading_risk_gate
- Removedtrading_stats
- Removedtrading_strategy_compile
- Removedtrading_wallet
- Removedtranslate
- Removedvideo_create
- Removedvoice_transcribe
- Removedweather
- Removedworkout_build
- Removedwrite
- Removedzambo_agent_bootstrap
- Removedzambo_ask
- Removedzambo_brief
- Removedzambo_check
- Removedzambo_compare
- Removedzambo_compose
- Removedzambo_help
- Removedzambo_limit
- Removedzambo_mesh
- Removedzambo_playbook
- Removedzambo_pulse
- Removedzambo_recall
- Removedzambo_remember
- Removedzambo_score
- Removedzambo_session
- Removedzambo_share
- Removedzambo_spread
- Removedzambo_swarm
- Removedzambo_token
- Removedzambo_verified
- Removedzambo_watch
- Removedzambot_chain
- Removedzambot_drift
- Removedzambot_fix
- Removedzambot_legendary_spark
- Removedzambot_outcome
- Removedzambot_registry
- Removedzambot_swarm_debate
- Removedzambot_verify
- Removedzambro_analyze

1 tool updateSep 5, 2026

Changedtokendiet_cache3 fields changed

changedInput schema / properties / action / description

Previous value: -"stats | flush_tool | flush_all"New value: +"stats"

addedInput schema / properties / action / enum
```
Added value: +[
+  "stats"
+]
```

removedInput schema / properties / tool

Removed value: -{
-  "description": "Tool name for flush_tool action.",
-  "type": "string"
-}

19 tool updatesSep 4, 2026

Changedhitl_submit4 fields changed
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / review_id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / submitted
```
Added value: +{
+  "type": "boolean"
+}
```
Changedmcp_extend4 fields changed
- addedOutput schema / properties / calls_added
```
Added value: +{
+  "type": "number"
+}
```
- addedOutput schema / properties / email
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / granted
```
Added value: +{
+  "type": "boolean"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
Changedpartner_register4 fields changed
- addedOutput schema / properties / partner_id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / registered
```
Added value: +{
+  "type": "boolean"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_act5 fields changed

addedInput schema / properties / approval_token

Added value: +{
+  "description": "Scoped, expiring, single-use token returned after explicit approval. Retry the unchanged action with this token.",
+  "type": "string"
+}

addedOutput schema / properties / action
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_extract4 fields changed

addedOutput schema / properties / links

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / text
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / title
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_navigate6 fields changed

addedInput schema / properties / approval_token

Added value: +{
+  "description": "Scoped, expiring, single-use token returned after explicit approval. Retry the unchanged action with this token.",
+  "type": "string"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / text
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / title
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / url
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_post6 fields changed

addedInput schema / properties / approval_token

Added value: +{
+  "description": "Scoped, expiring, single-use token returned after explicit approval. Retry the unchanged post with this token.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "platform",
-  "content"
-]New value: +[
+  "identity_id",
+  "platform",
+  "content",
+  "access_key"
+]

addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / platform
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_reply5 fields changed

addedInput schema / properties / approval_token

Added value: +{
+  "description": "Scoped, expiring, single-use token returned after explicit approval. Retry the unchanged reply with this token.",
+  "type": "string"
+}

addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / platform
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_screenshot4 fields changed

addedOutput schema / properties / links

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / text
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / title
```
Added value: +{
+  "type": "string"
+}
```

Changedpresence_session_attach4 fields changed
- addedOutput schema / properties / attached
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```
Changedpresence_session_create4 fields changed
- addedOutput schema / properties / access_key
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```
Changedpresence_session_kill4 fields changed
- addedOutput schema / properties / identity_id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / killed
```
Added value: +{
+  "type": "boolean"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```
Changedpresence_session_list3 fields changed
- addedOutput schema / properties / count
```
Added value: +{
+  "type": "number"
+}
```
- addedOutput schema / properties / identities
```
Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
Changedsignal_register4 fields changed
- addedOutput schema / properties / handle
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / profile_url
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / registered
```
Added value: +{
+  "type": "boolean"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```

Changedtrading_journal4 fields changed

addedInput schema / properties / owner_capability

Added value: +{
+  "description": "Owner capability returned by trading_strategy_compile. Required for writes; omit for reads.",
+  "minLength": 32,
+  "type": "string"
+}

addedOutput schema / properties / entry

Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedtrading_propose6 fields changed

addedInput schema / properties / owner_capability

Added value: +{
+  "description": "Non-forgeable owner capability returned by trading_strategy_compile. Required for every strategy mutation; do not share it.",
+  "minLength": 32,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "strategy_id",
-  "signal"
-]New value: +[
+  "strategy_id",
+  "owner_capability",
+  "signal"
+]

addedOutput schema / properties / approval_required
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / proposal_id
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / status
```
Added value: +{
+  "type": "string"
+}
```

Changedtrading_wallet6 fields changed

removedInput schema / properties / email

Removed value: -{
-  "description": "Your email for ownership verification.",
-  "type": "string"
-}

addedInput schema / properties / owner_capability

Added value: +{
+  "description": "Owner capability returned by trading_strategy_compile.",
+  "minLength": 32,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "strategy_id",
-  "wallet_address"
-]New value: +[
+  "strategy_id",
+  "owner_capability",
+  "wallet_address"
+]

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / updated
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / wallet
```
Added value: +{
+  "type": "string"
+}
```

Changedzambo_playbook4 fields changed
- addedOutput schema / properties / action
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / playbook
```
Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
```
- addedOutput schema / properties / result / additionalProperties
```
Added value: +true
```
- changedOutput schema / properties / result / type
```
Previous value: -"string"New value: +"object"
```
Changedzambo_share4 fields changed
- addedOutput schema / properties / id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / public
```
Added value: +{
+  "type": "boolean"
+}
```
- removedOutput schema / properties / result
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / share_url
```
Added value: +{
+  "type": "string"
+}
```

9 tool updatesSep 4, 2026

Changedpresence_act2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "action"
-]New value: +[
+  "identity_id",
+  "action",
+  "access_key"
+]

Changedpresence_extract2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "url"
-]New value: +[
+  "identity_id",
+  "url",
+  "access_key"
+]

Changedpresence_navigate2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "url"
-]New value: +[
+  "identity_id",
+  "url",
+  "access_key"
+]

Changedpresence_post1 field changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Required when identity_id is supplied. Presence access key returned at identity creation; sent only as X-Presence-Key.",
+  "minLength": 21,
+  "type": "string"
+}

Changedpresence_reply2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "platform",
-  "target_id",
-  "content"
-]New value: +[
+  "identity_id",
+  "platform",
+  "target_id",
+  "content",
+  "access_key"
+]

Changedpresence_screenshot2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "url"
-]New value: +[
+  "identity_id",
+  "url",
+  "access_key"
+]

Changedpresence_session_attach2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id",
-  "cookies_json"
-]New value: +[
+  "identity_id",
+  "cookies_json",
+  "access_key"
+]

Changedpresence_session_kill2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "identity_id"
-]New value: +[
+  "identity_id",
+  "access_key"
+]

Changedpresence_session_list2 fields changed

addedInput schema / properties / access_key

Added value: +{
+  "description": "Presence access key returned at identity creation. Sent only as X-Presence-Key; do not store or share it.",
+  "minLength": 21,
+  "type": "string"
+}

addedInput schema / required
```
Added value: +[
+  "access_key"
+]
```

1 tool updateSep 3, 2026

Changedtrading_journal1 field changed

changedInput schema / properties / strategy_id / description

Previous value: -"Filter read history by strategy_id."New value: +"The strategy_id from trading_propose. Required for journal writes; also filters reads."

1 tool updateSep 3, 2026

Changedaxis_mcp_access3 fields changed

addedOutput schema / properties / advanced_direct_axis_config

Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

removedOutput schema / properties / combined_config

Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}

addedOutput schema / properties / default_config

Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

1 tool updateSep 3, 2026

Changedagent_hire10 fields changed

removedInput schema / properties / budget_usdc

Removed value: -{
-  "description": "For hire: your USDC budget for the task",
-  "type": "number"
-}

addedInput schema / properties / buyer_email

Added value: +{
+  "description": "For hire: email used to track the hire and receive status updates",
+  "type": "string"
+}

addedInput schema / properties / buyer_wallet

Added value: +{
+  "description": "For hire: optional buyer Base wallet",
+  "type": "string"
+}

addedInput schema / properties / hire_id

Added value: +{
+  "description": "For hire payment retry: hire_id returned by the 402 challenge",
+  "type": "string"
+}

addedInput schema / properties / listing_id

Added value: +{
+  "description": "For hire: exact listing_id returned by agent_hire({action:'browse'}). Required for a real marketplace hire.",
+  "type": "string"
+}

addedInput schema / properties / owner_email

Added value: +{
+  "description": "For list: email for marketplace ownership and hire notifications",
+  "type": "string"
+}

addedInput schema / properties / owner_wallet

Added value: +{
+  "description": "For list: optional Base wallet that receives the agent's 90% share",
+  "type": "string"
+}

addedInput schema / properties / payment_hash

Added value: +{
+  "description": "For hire payment retry: Base transaction hash after sending the exact USDC amount",
+  "type": "string"
+}

addedInput schema / properties / payment_scheme

Added value: +{
+  "description": "For hire payment retry: exact for immediate handoff (default), escrow for delivery confirmation followed by manual settlement review",
+  "enum": [
+    "exact",
+    "escrow"
+  ],
+  "type": "string"
+}

changedInput schema / properties / specialization / description

Previous value: -"For browse: filter agents by skill (e.g. 'solidity audit', 'content', 'data analysis')"New value: +"For browse: filter listings by skill (e.g. 'solidity audit', 'content', 'data analysis')"

3 tool updatesSep 3, 2026

Changedcapability_search3 fields changed

changedInput schema / properties / q / description

Previous value: -"Search keyword or phrase. Example: 'code audit', 'prompt injection defense', 'wallet scoring', 'lead generation', 'trust verification'"New value: +"Search keyword or phrase. Also accepts the natural aliases query, keyword, or search. Example: 'code audit', 'prompt injection defense', 'wallet scoring', 'lead generation', 'trust verification'"

addedInput schema / properties / query

Added value: +{
+  "description": "Alias for q. Use q when possible.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "q"
-]New value: +[]

Changedzambo_ask1 field changed

changedInput schema / properties / q / description

Previous value: -"Your question about zambo.dev or any of its 100+ tools across 2 MCPs. Also accepts: question, ask. Examples: 'What is ZAMBRO?', 'How does Zambo Pass work?', 'What is ZAMBOT Swarm Debate?', 'What endpoints are free?'"New value: +"Your question about zambo.dev or any of its 100+ tools available through one MCP connection. Also accepts: question, ask. Examples: 'What is ZAMBRO?', 'How does Zambo Pass work?', 'What is ZAMBOT Swarm Debate?', 'What endpoints are free?'"

Changedzambo_universal1 field changed

addedInput schema / properties / email

Added value: +{
+  "description": "Optional email, only with the user's consent. Namespaces Pass access and a compact working trail so the same user can continue across AI clients without restarting.",
+  "type": "string"
+}

128 tool updatesSep 3, 2026

Changedagent_brief1 field changed