Rank a competitor's EU App Store ads by longevity. From Apple's official Ad Repository.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 17 of 17 tools scored.
Each tool has a clear, distinct purpose. The status checkers (assemble_status, clips_status) are differentiated by the job type they monitor. Memory tools (index, note, recall) are distinct operations. Competitor ad tools (search, get ads, get details) and video generation pipeline (avatar, clips, assembly) are well-separated.
All tools use consistent snake_case with a verb_noun or noun_verb pattern (e.g., assemble_video, get_competitor_ads, memory_index). No mixing of conventions, making the tool names predictable and easy to understand.
With 17 tools, the server covers account management, memory, competitor research, and video generation without being overwhelming. The count is well-scoped for its functionality, neither too sparse nor too heavy.
The toolset covers the core workflows: account setup (sign_up, upgrade, whoami), memory (CRUD), competitor analysis (search, get ads, details), and video ad creation (avatar, clips, assembly). Minor gaps like lacking a delete memory tool are acceptable given the domain focus.
assemble_statusACheck an assemble_video job by its job_id. Returns the status (processing, done, or error). When done, returns the final MP4 url, the aspect, clip count, total duration, and the booked cost in EUR. When it errored, returns the reason. Only jobs on your own account are visible.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by assemble_video |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and readOnlyHint=true. The description adds useful behavioral details: return format for done (MP4 url, aspect, etc.) and error (reason), plus account visibility constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with four sentences that are front-loaded with the primary purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key return states (processing, done, error) with specific fields. It also notes account visibility. Could mention behavior for invalid job_ids, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description is already provided by the schema. The tool description does not add additional semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks an assemble_video job by job_id and returns status. It specifies the resource (assemble_video job) and distinguishes from siblings like clips_status or assemble_video itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates to use with job_id from assemble_video and notes that only jobs on the user's own account are visible. While it doesn't explicitly state when not to use, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
assemble_videoAInspectStitch rendered scene clips into one ad-ready MP4 with burned-in subtitles and crossfades. Pass 1 to 6 clips in order, each with its mp4 url, its duration in seconds (3 to 12), and an optional subtitle line to burn over that clip. Every clip is scaled and padded to the chosen aspect (9:16 default 1080x1920, 1:1 1080x1080, or 16:9 1920x1080). Optional intro and outro title cards: pass intro/outro as { text, duration_s? } to bookend the ad with a centred title card (1 to 5 seconds, default 2) that crossfades into the video; cards do not count toward the 6-clip limit. Assembly is our compute, so it carries a small flat fee (about 0.12 EUR), booked only when the file is produced, against your trust cap. Runs in the background over up to a couple of minutes and returns a job_id: poll assemble_status with it to get the finished MP4 url. Feed it the clips from clips_status (map each to url, duration_s, subtitle). Paid plans only.
| Name | Required | Description | Default |
|---|---|---|---|
| clips | Yes | 1 to 6 clips in playback order | |
| intro | No | Optional intro title card shown before the clips. | |
| outro | No | Optional outro title card shown after the clips (e.g. a call to action). | |
| aspect | No | Output aspect ratio: 9:16 (default, 1080x1920), 1:1 (1080x1080), or 16:9 (1920x1080). | 9:16 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations, including that assembly carries a flat fee, runs in the background, returns a job_id for polling, and is non-idempotent. It aligns with annotations (readOnlyHint: false, idempotentHint: false) and provides specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds necessary information. It is well-structured: starting with the core action, then input details, fees, async behavior, and links to related tools. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: input, constraints, fees, background processing, output as job_id, polling with assemble_status, and references to clips_status. Given the complexity of the tool, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining constraints like clip limit 1-6, duration range 3-12, and the fact that intro/outro cards don't count toward the clip limit. This augments the schema descriptions effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: stitching rendered scene clips into an ad-ready MP4 with subtitles and crossfades. It distinguishes itself from siblings like assemble_status and clips_status by specifying that it consumes clips from clips_status and returns a job_id to poll with assemble_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: after having rendered clips, to create a final ad. It mentions it's for paid plans only and guides the user to feed clips from clips_status. While it doesn't explicitly state when not to use it, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clips_statusACheck a generate_clips render job by its job_id. Returns the status (processing, done, or error). When done, returns the finished clip URLs, the model used, and the booked cost in EUR. When it errored, returns the reason. Only jobs on your own account are visible.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by generate_clips with confirm=true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. The description adds details on return values for different statuses (done vs error), including URLs, model, cost, and reason, plus account restriction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that efficiently cover purpose, success case, error case, and limitation. No unnecessary words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one parameter and no output schema, the description explains return values and constraints adequately. Could mention if output has additional fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes job_id well. The description does not add significant parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a generate_clips render job by job_id, with specific status outcomes. It distinguishes from sibling tools like generate_clips (which creates jobs) and other status tools by focusing on clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after calling generate_clips with confirm=true and mentions the account visibility constraint. However, it does not explicitly state when not to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_avatarAInspectGenerate a UGC persona: your agent passes a persona brief (physical look plus vibe of one invented creator), and we return stills of that invented person plus an avatar_id. The persona brief anchors the same character in generate_clips takes, and the stills are the customer's reference artifact for the creative. Ask for up to 3; the default model returns a single strong base still, imagen and flux return the full set. Metered per generation; the price is shown in the response. Paid plans only.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many stills to request (2 to 3). The default model returns 1 regardless; imagen and flux honor this. | |
| model | No | Image model. Default seedream-4.0 (lowest cost). | bytedance/seedream-4.0 |
| persona_brief | Yes | Physical description plus vibe of the invented UGC creator. One person (age, look, styling, setting, energy). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set openWorldHint=true and destructiveHint=false. The description adds behavioral context: metered generation, price in response, paid plans only, and model-dependent count behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but slightly long; each sentence adds value. It is front-loaded with the main action. Minor redundancy with 'stills' mentioned twice could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with full schema coverage, no output schema, and annotations, the description covers key aspects: action, input, output, pricing, plan restriction, and model differences. It is complete enough for effective use without missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema: explains count is only honored by imagen/flux (not default), elaborates persona_brief content (age, look, styling, setting, energy), and notes model defaults to lowest cost. This significantly aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a UGC persona (avatar) based on a persona brief, returning stills and an avatar_id. It distinguishes from sibling generate_clips by noting the persona brief anchors the same character and stills are a reference artifact. The verb 'generate' and resource 'avatar' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need UGC persona stills/avatar) and references generate_clips as related, but lacks explicit when-not-to-use or alternatives beyond that single sibling. The 'Paid plans only' restriction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_clipsARender UGC video scenes as ad-ready clips, metered per second of video (the estimate shows the exact price before anything renders). Pass 3 to 6 scenes (5 to 8 seconds each, one action per scene, spoken lines at most 20 words; empty spoken_line for silent characters). Consecutive scenes pack into single TAKES of up to 15 seconds, one generation each. HOW CHARACTER IDENTITY WORKS, read carefully: all characters are described in TEXT (avatar_id resolves to its persona brief; or write the persona field yourself, covering one character or a whole ensemble). The video model rejects every image that contains a person, so no photo can anchor a face. Text keeps a character IDENTICAL only WITHIN a take; ACROSS takes it preserves the look and styling but the exact face can drift, and neither avatar_id nor persona prevents that. Structure your script so scenes where the same character must be recognizably identical sit adjacent and fit one take (15s or less); treat cross-take appearances as different shots of a matching character, and review the result. reference_image_urls (up to 9 https images) keeps real products or props on-model in every take; these images must contain no people. Without confirm, it validates the contract and returns the per-scene price estimate in EUR, and makes nothing. With confirm=true it starts the metered render and returns a job_id: rendering runs in the background over a few minutes, so poll clips_status with that id to get per-scene clip URLs plus the uncut takes. Paid plans only.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | seedance-2.0 (default, highest quality) or seedance-2.0-fast (same generation, faster and cheaper). | bytedance/seedance-2.0 |
| aspect | No | Output aspect ratio | 9:16 |
| scenes | Yes | 3 to 6 scenes in order. Adjacent scenes sharing a character land in the same take when their combined length allows it. | |
| confirm | No | Set true to start the metered render. Returns a job_id to poll with clips_status. | |
| persona | No | Alternative to avatar_id: describe the recurring character or the full ensemble (several characters) in words. Same limits: identity holds within a take, not across takes. Ignored when avatar_id is present. | |
| avatar_id | No | Avatar id from generate_avatar (starts with av_). Its persona brief describes the recurring character in text; identity holds within a take only, not across takes. | |
| reference_image_urls | No | Up to 9 https image URLs of products or props to keep on-model in every take. No people in these images. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures go well beyond annotations: pre-render validation, metered pricing with estimate, background rendering, character identity drift across takes, video model rejecting images with people, and reference image constraints. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense with every sentence earning its place. However, the character identity section is quite long and could benefit from better structure (e.g., bullet points). Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (1 required) and no output schema, the description covers all relevant aspects: pre-render behavior, render initiation, background polling, character constraints, pricing, and usage prerequisites. It compensates for lack of output schema by describing return values (price estimate, job_id, clip URLs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds critical meaning: explains how avatar_id and persona affect character identity, that confirm triggers render, that reference images must be people-free, and how scenes combine into takes. This is essential context not inferable from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Render UGC video scenes as ad-ready clips', clearly stating the verb (render) and resource (UGC video scenes). It also distinguishes from siblings like clips_status (polling) and generate_avatar (avatar creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidelines: confirm=false for validation/estimate, confirm=true for actual render. Specifies scene count (3-6), duration (5-8s), spoken line limit (20 words), character identity behavior across takes, and that reference images must have no people. Also mentions alternatives avatar_id vs persona.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ad_detailsAGet full details and locale/creative variations for one specific ad (use adId from get_competitor_ads). Shows every language variant, creative asset URLs, and icon variations. Useful to see how a competitor localizes a winning ad.
| Name | Required | Description | Default |
|---|---|---|---|
| adId | Yes | ||
| datePreset | No | LAST_YEAR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the output: every language variant, creative asset URLs, and icon variations. This goes beyond annotations, but does not mention any other behavioral traits like rate limits or result size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the primary function, second provides a concrete use case. No redundant or vague wording. Information is front-loaded and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, one required), rich annotations, and absence of an output schema, the description covers the purpose, output contents, and links to the sibling tool. However, it omits explanation of the datePreset parameter, which would improve completeness for agents needing time-range filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It clarifies that adId comes from get_competitor_ads, but does not explain the datePreset parameter (only an enum and default in schema). The description fails to compensate for the lack of parameter documentation, especially for the optional but functional datePreset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details including locale/creative variations for one specific ad. It specifies using adId from get_competitor_ads, distinguishing it from sibling tools like get_competitor_ads (which lists ads) and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the adId from get_competitor_ads and provides a use case (seeing how a competitor localizes an ad). However, it does not explicitly state when not to use this tool or mention alternatives beyond the implied source of adId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_competitor_adsAGet all Apple App Store ads a competitor has run (EU storefronts, up to 1 year back), with creative copy, placements, formats, and an inferred winner analysis: ads sorted by how long they've been running (longevity = the advertiser keeps paying = likely converting). Source: official Apple Ad Repository (DSA transparency data).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | appId or developerId from search_app_advertiser | |
| type | No | APP | |
| countries | No | EU country codes to filter (default: all 25). Available: AT,BE,BG,HR,CY,CZ,DK,EE,FI,FR,DE,GR,HU,IE,IT,LV,LU,NL,PL,PT,RO,SK,SI,ES,SE | |
| datePreset | No | LAST_YEAR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, open world), the description adds the data source (Apple Ad Repository, DSA transparency data), sorting logic (by longevity indicating likely converting), and constraints (EU storefronts, 1-year lookback). This provides valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes essential details without fluff. Every part serves a purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers core functionality, data source, and output characteristics (sorted list with winner analysis). It lacks details on pagination or response format, but overall is fairly complete for a read-only data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description does not add detailed meaning for parameters beyond what's in the schema. It mentions that id comes from search_app_advertiser, which is useful, but overall parameter semantics are minimally enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all Apple App Store ads a competitor has run, with specific attributes like creative copy, placements, formats, and a winner analysis sorted by ad longevity. It distinguishes from siblings like get_ad_details and get_playbook by focusing on aggregate competitor intelligence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is contingent on first obtaining an id from search_app_advertiser, but it does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance. The context from sibling tools is not leveraged in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_playbookAGet a Recao GTM playbook: the go-to-market moves a solo app founder's agent runs, wired to the competitor data tools. Start with 'the-roadmap' (diagnoses the founder's stage and its binding constraint, then routes you to the right playbook). Call with no slug to list all playbooks.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds minimal behavioral context beyond 'get' and 'list', which is consistent but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and contains no wasted words. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single optional parameter, the description fully covers usage, context (wired to competitor tools), and integration advice (start with 'the-roadmap').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the optional slug parameter's effect (list vs. get specific playbook), adding value beyond the schema which only defines it as a string. However, it doesn't detail what a slug represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a Recao GTM playbook and explains behavior when no slug is provided. It provides specific context about the target user and system integration, but does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: start with 'the-roadmap' to diagnose stage before using this tool, and call with no slug to list all playbooks. This clearly communicates when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_indexAList this account's company memory, one line per entry (name + description), newest first. Traverse index-first: scan this, then memory_recall(name) for full bodies. Memory accrues automatically from your competitor scans (exhaust) and from your own memory_note writes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by detailing output format, ordering, and automatic memory accumulation from competitor scans and memory_note writes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and efficient explanation of usage and data sources. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only index tool with no output schema, the description fully covers what the tool returns (one line per entry, name+description, newest first) and how memory is populated, meeting completeness needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% trivially. Baseline 4 applies, and description adds no parameter-specific detail but explains the tool's behavior adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), resource ('company memory'), and details format ('one line per entry (name + description), newest first'). It clearly distinguishes from siblings like memory_recall and memory_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Traverse index-first: scan this, then memory_recall(name) for full bodies,' providing a clear workflow. Also explains how memory accrues, informing when the index is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_noteAWrite (or update) a memory entry on this account: decisions, campaign outcomes, learnings. Use a short kebab-case name and a one-line description (that's the index line); details go in body. Your future sessions and Recao's weekly reports read this.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Full content (markdown fine) | |
| name | Yes | Short kebab-case slug, e.g. 'campaign-tiktok-hooks-june' | |
| description | Yes | One-line summary for the index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. Description adds behavioral context: it writes/updates storing the entry, and that it persists across sessions and is read by weekly reports. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no filler. Every sentence earns its place, covering action, usage, and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters, no output schema, and sibling tools that indicate a broader system, the description provides enough context: what to write, how to format, and where the data goes. Could mention whether updates are destructive (overwrite) but annotations cover idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining naming convention (kebab-case), that description is a one-line index, and that body supports markdown. This goes beyond schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the action (write/update) and resource (memory entry), and specifies categories (decisions, campaign outcomes, learnings). It distinguishes from sibling tools like memory_index and memory_recall by mentioning that future sessions and weekly reports read this data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on parameter usage (kebab-case name, one-line description for index, details in body) and mentions the context where output is used (future sessions, weekly reports). Lacks explicit when-not-to-use or alternatives, but sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_recallARead one memory entry's full body by name (get names from memory_index).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Memory name (kebab-case slug from memory_index) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral details beyond the annotation set, which is sufficient given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a parenthetical hint provides all necessary information without redundancy. It is front-loaded with the core action and supplemental context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description indicates the scope ('full body') which is reasonable for a recall operation. Minor gap: it does not specify the return format, but this is mitigated by the tool's simplicity and the explicit data source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description merely restates that the tool reads by name. The schema already documents the format requirement (kebab-case), so the description adds no additional semantic value beyond confirming the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Read', the resource 'one memory entry', and specifies how to get valid names via 'memory_index'. It clearly distinguishes itself from the sibling tool memory_index by mentioning the source of names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to get names from memory_index before using this tool, providing a clear prerequisite. It does not explicitly list when not to use or alternative tools, but the reference to memory_index implies a structured workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
roadmap_statusAWhere the founder's agent starts its go-to-market work: diagnose which stage of the Recao Roadmap this account is in (S0 pre-launch to S4 scale), the binding constraint, and the playbook to run. Reads your scans and memory. Sharpen it: write a memory_note named 'company-stage' with your MRR band and funnel numbers, and this tool will use it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds that it 'reads your scans and memory' and can be improved by writing a memory note, which provides moderate additional behavioral context beyond annotations. However, it does not cover potential side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences that front-load the core purpose, then detail what it reads, and finally provide a tip. Every sentence serves a purpose without redundancy or excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, how it works, and how to improve results. It does not specify the output format (since no output schema exists), but the mention of diagnosing stage, constraint, and playbook gives a reasonable expectation. A minor completeness gap exists regarding the return structure, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0), so schema coverage is 100% by default. The description adds value by explaining that the tool uses existing scans and memory, and suggests a preparatory action (write a memory_note) to sharpen results. This is additive and actionable, fully compensating for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'diagnose which stage of the Recao Roadmap this account is in (S0 pre-launch to S4 scale), the binding constraint, and the playbook to run.' It uses a specific verb (diagnose) and resource (roadmap stage), and the context of being the starting point distinguishes it from sibling tools like get_playbook or assemble_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests this is the starting point for go-to-market work, but it does not explicitly mention when to avoid it or compare to alternatives like get_playbook or memory_note. The tip about writing a memory_note provides indirect usage guidance, but it lacks clear when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_app_advertiserASearch the Apple Ad Repository for apps or developers advertising on the EU App Store. Returns ids to use with get_competitor_ads. Start here with your competitor's app name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | App or developer name to search for | |
| types | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the search is limited to the EU App Store and returns IDs for downstream use, which is helpful context but does not disclose potential limitations like result limits or case sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It front-loads the tool's purpose and closes with a clear next step, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the core functionality, return value (IDs), and a clear starting use case. However, it omits details on the 'types' parameter and potential search behaviors like pagination or wildcards, which would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (name has a description, types does not). The description mentions 'your competitor's app name' to clarify the 'name' parameter, but does not address the 'types' parameter beyond its enum values. Given the low coverage, the description provides partial but insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Apple Ad Repository for apps or developers on the EU App Store, and specifies it returns IDs for use with get_competitor_ads. It uses a specific verb ('Search') and resource ('Apple Ad Repository'), distinguishing it from sibling tools like get_competitor_ads and get_ad_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Start here with your competitor's app name,' providing a clear entry point for competitor analysis. However, it does not explicitly mention when to avoid this tool or list alternative search methods, though the context of the sibling tools implies its primary role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sign_upARequest a free Recao account for your human. This does NOT create an active account: it registers a PENDING one and emails your human an activation link; nothing works and no terms are accepted until they click it (the human accepts the terms at activation, not you). The API key in the response stays inert until then. Consent stays with the human, so calling this is a request, not a decision made for them: in an interactive session their approval of this tool call is the go-ahead; if you run autonomously, surface this step to your human instead of calling it. After activation, reconnect with header Authorization: Bearer <key>.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The account owner's email (the human founder's) | ||
| app_name | No | The user's own app (App Store name), so reports and memory attach to it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations, such as the pending nature, inert API key, human consent, and the need to reconnect after activation. Annotations (idempotentHint: true, destructiveHint: false) are consistent with the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite length, every sentence adds essential information. Well-structured with purpose upfront and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema, the description explains the response (inert API key) and post-activation steps, making it complete for a sign-up tool with 2 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions; the description adds context like 'human founder's' for email and 'App Store name' for app_name, slightly enhancing clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request a free Recao account for your human' and explains the pending account creation process, distinguishing it from other tools by its specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use and when-not-to-use, including guidance for interactive vs. autonomous sessions: 'if you run autonomously, surface this step to your human instead of calling it.' It also clarifies that activation requires human action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upgradeAGet the checkout link to upgrade this account to a paid plan (Indie €29/mo: 10 competitors + weekly auto-reports; Pro €79/mo: 25 competitors, new channels first, full API). Payment happens in the browser. Hand the link to the human.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but description adds that payment happens in the browser, clarifying the tool's non-destructive nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: action, payment context, agent instruction. No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies the outcome (checkout link) but lacks detail on link format or prerequisites. Adequate for a simple tool, but could mention account requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'plan' has an enum but no schema description (0% coverage). The description fully compensates by listing each plan's features and pricing, adding meaning beyond enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'checkout link to upgrade this account', with plan details. Distinguishes from sibling tools by its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to hand the link to the human, implying the agent should not follow it. Provides context on when to use (upgrading account) but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
usageAShow this account's metered generation spend this period and its billing position: the usage cap, what has accrued toward it, and whether generation is waiting on a payment. Use it to report costs back to your human.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds context about showing billing position and payment dependency, which supplements the structured data without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences deliver the full purpose and usage guidance with no waste. The key elements are front-loaded, making it easy for an agent to quickly understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description fully satisfies the need by detailing what information is displayed. No gaps remain for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to explain parameters, and it adds no irrelevant detail. A baseline score of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool shows 'metered generation spend this period and its billing position', including specific items like usage cap, accrued amount, and payment status. This provides a clear verb-resource pairing and distinguishes from sibling tools like 'get_playbook' or 'assemble_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description ends with 'Use it to report costs back to your human.', offering a clear use case. While it does not explicitly list when not to use it or compare to alternatives, the context of sibling tools makes the purpose distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAShow the authenticated account (plan, email, verification state), or confirm you're anonymous.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. Description adds value by detailing output content (plan, email, verification state) and the anonymous confirmation case, which annotations don't specify. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, fully front-loaded, no redundant words. Every word contributes meaning. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a read-only info tool with no parameters and no output schema. Describes both authenticated and anonymous cases. Could mention error handling or exact output format, but given low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema (100% coverage). With zero parameters, baseline is 4. Description doesn't need to add parameter info; it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Show' and resource 'authenticated account' with explicit details (plan, email, verification state). It clearly distinguishes from sibling tools like memory_recall or generate_avatar by focusing on identity and authentication status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It implies use for checking current identity but doesn't specify scenarios like before performing authenticated actions or when to expect anonymous response. Missing when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.