@orchyn/mcp

Official

by orchynX

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.26.17
Disambiguation3/5
Most tools have explicit cross-references that separate discovery, fetching, analysis, and creation, which helps an agent choose correctly. However, analyze_post and understand_social_post overlap heavily in inputs, platforms, credit cost, and output focus, and the many analyze/discover/creator tools still require careful reading to avoid misselection.
Naming Consistency4/5
The overwhelming majority follow a clear snake_case verb_noun pattern like get_user_posts, analyze_comments, and write_hooks. Minor deviations such as analyze_post_fast, niche_report, and orchyn_login break the pattern slightly but remain readable and predictable.
Tool Count3/5
27 tools is on the heavy side, and some sub-areas like post analysis, creator research, and content generation could be consolidated. The broad scope across eight social platforms and the paid-credit workflow partly justifies the count, so it feels bloated but not chaotic.
Completeness4/5
The domain is well covered: discovery, media/transcript/comment retrieval, multi-level analysis, content creation, creator watchlists, and credit/auth management are all present. Minor gaps exist, such as no direct way to list watched creators or fetch a creator's raw profile stats without triggering analysis, but agents can work around them.
Average 4.4/5 across 27 of 27 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 160 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful non-obvious operational context: it consumes 2 orchyn credits and reads the real transcript when given a URL. This goes beyond what annotations provide and does not contradict them.
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?
Three short sentences deliver purpose, input modes, cost, and when-to-use with no fluff. The information is front-loaded. Minor formatting typo ('consumes 2 orchyn credits.Use') slightly reduces polish but not clarity.
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 rich schema, output schema, and annotations, the description covers the essential facts: what it produces, how to invoke it, credit cost, and when to use it. It could still offer stronger differentiation from related content-creation siblings, but nothing critical is missing for a correct 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?
The schema covers all four parameters with descriptions, including optionality, count defaults, and max value. The description's 'url vs topic' framing reinforces the schema but adds no new semantic meaning beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Write') and resource ('opening hooks') and defines them as 'the first line said or shown on screen.' It does not explicitly differentiate from sibling tools like create_variants or find_hook_pattern, so it stops short of full sibling differentiation.
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 ends with clear when-to-use guidance: 'Use when you know the subject and need openings to choose between.' It provides a practical trigger but does not include explicit when-not-to-use conditions or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not burdened with the safety profile. It adds meaningful context beyond the annotations by disclosing the cost ('Consumes 6 orchyn credits') and by detailing what the returned analysis contains. Nothing in the description 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is front-loaded and dense with useful detail, and the credit-cost note earns its place. But the final sentence ('Use when the goal is what to make next rather than what people wrote.') is a near-duplicate of the second sentence — clear redundancy that should have been edited out, dropping this from a 4 to a 3.
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 read-only tool with two well-documented parameters and an output schema present, the description covers the essentials: what it does, what it returns, when to use it, and the cost. The only meaningful gap is that it doesn't name the alternative tool (get_post_comments) explicitly, and the duplicated usage line is space that could have been used for that.
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%: url is documented as 'Full public post URL' and limit as 'Comments to read (default 50, max 100)'. The description adds only marginal parameter-level meaning by implying the url must point to a post ('Read a post's comment section'), so the baseline of 3 for fully-covered schemas is appropriate.
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 ('Read a post's comment section') and enumerates the concrete outputs: sentiment, recurring themes, questions, objections, content requests, language, and follow-up video ideas. It explicitly contrasts itself with getting raw comments ('what should I make next' rather than 'what did people write'), which distinguishes it from the sibling get_post_comments without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use signal: 'Use when the goal is what should I make next rather than what did people write.' This clearly frames the decision context and implies the alternative (raw comment retrieval). However, it does not name the sibling tool explicitly nor state a when-not-to-use condition, and the guidance is stated twice, which slightly dilutes its precision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful non-obvious context: the tool consumes 2 orchyn credits and returns creator fields such as follower count, signature, and verified status. No contradiction with annotations, and the credit cost is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the core purpose first, then cost, then usage guidance. There is no filler, no tautology, and 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 simple search tool with full schema coverage, an output schema, and safety annotations, the description covers purpose, usage context, and cost. The only notable completeness gap is the inaccurate platform list, which could prevent correct invocation if an agent trusts the description over the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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, but the description actively contradicts the schema by advertising YouTube and Douyin as platform options while the enum only supports tiktok, instagram, and xiaohongshu. It also adds no parameter-level detail beyond what the schema already provides, so the misinformation lowers the 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 names a specific action ('Search creators'), a clear resource, and search criteria (niche/keyword, platform), and it distinguishes itself from get_similar_creators. However, it lists YouTube and Douyin as supported platforms even though the schema's platform enum only allows tiktok, instagram, and xiaohongshu, making its stated scope partially inaccurate.
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?
Explicitly states the decision rule: use this tool when you know the niche but not names, and use get_similar_creators when you already have a working creator. This is exactly the kind of when-to-use/when-not-to-use guidance that helps an agent select the right sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true, and the description adds useful context: 'Nothing is fetched, so there is no cost.' This goes beyond the schema and annotations by clarifying the operation is local and free, which is valuable for an agent deciding whether to call it.
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 efficient, but 'Nothing is fetched, so there is no cost' and 'No cost to call' are redundant. The duplication is unnecessary and slightly hurts the conciseness score.
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 mutation with two well-documented parameters and annotations covering destructiveness and idempotency, the description is complete enough. It lacks a return-value explanation, but no output schema exists and the operation is straightforwardly a destructive removal.
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 both parameters (platform and username) are already documented. The description does not add any additional parameter semantics beyond reaffirming 'creator' maps to the username field, so the baseline of 3 is appropriate.
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 uses a specific verb and resource: 'Remove a creator from your watchlist.' This clearly distinguishes it from sibling tools like watch_creator and catch_up_watchlist, which are about adding or viewing.
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 context is clear: use this when the goal is to remove a creator from the watchlist. It does not explicitly name alternatives or exclusions, but the intent is unambiguous and does not conflict with sibling tool purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds the 8-credit cost and details the analytical output structure (winner, differed attributes, shared strengths, testable lessons, next experiment), which goes beyond the structured annotations.
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 compact and front-loaded, but the final clause ('Use when two posts differ...') largely repeats the earlier trigger ('why did this one work and that one not'), and there is a spacing typo ('credits.Use'). It earns a passing but not exemplary score.
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 one-parameter tool with a rich output schema and annotations that already cover safety, the description is complete: it specifies the allowed input count, the business trigger, the cost, and the analytical output. Nothing critical is missing for correct selection and invocation.
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 fully documents the only parameter, urls, as '2-5 post URLs to compare.', and the description merely repeats the 2-5 range. With 100% schema coverage, the description adds no new semantic value, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Compare 2-5 posts side by side'), the resource (posts), and the unique output (performance gap explanation with winner, differences, strengths, lessons, next experiment). The focus on multi-post performance comparison clearly distinguishes it from sibling tools like analyze_post or analyze_post_fast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a use condition: 'Use when two posts differ in performance and you need to know why' and a plain-language trigger ('why did this one work and that one not'). It does not name alternative tools or state when not to use it, but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, and non-destructive; the description adds the credit cost ('Consumes 2 orchyn credits') and identifies the data source. This is useful behavioral context beyond the annotations. No contradictions with the annotations exist.
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 and mostly concise, but it repeats the sentence 'Use to find what to tag, or to spot a wave early.' and contains a missing-space typo ('credits.Use'). This knocks it down from a cleaner, more efficient description.
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 read-only discovery tool with a rich output schema, the description covers the source, the metrics returned, the available filters, the intended use cases, and the credit cost. Nothing essential for calling the tool correctly is missing.
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 schema already documents all four parameters. The description only mentions 'Filter by country and time window', which is a light summary and does not add meaning beyond the schema.
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 states a specific resource and result: 'Trending TikTok hashtags from the Creative Center trend board', and enumerates the data fields (post counts, view counts, rising/cooling/steady). This clearly distinguishes the tool from siblings such as discover_sounds and discover_social_posts.
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 gives explicit use guidance: 'Use to find what to tag, or to spot a wave early.' This tells the agent when the tool is appropriate. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds meaningful context by disclosing that the call consumes 2 orchyn credits and mentioning the free credit allowance. No contradiction with the annotations exists; rate limits or other operational details are absent but not expected given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the subsequent sentences about scaling and credit cost each earn their place. There is a minor formatting run-on ('users).Use') and the description is slightly dense, but it is still concise overall.
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 read-only tool with only two parameters, an output schema, and rich annotations, the description covers purpose, platform options, credit cost, and the right usage scenario. Nothing critical is missing for an agent to select and invoke the tool correctly.
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 provides full descriptions for both parameters, including the platform enum default and a seed handle example. With 100% schema coverage, the description's references to a handle and platform add little beyond the structured fields, so the baseline 3 is appropriate.
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 states a specific action and resource: 'Find lookalike creators for a given handle' and further scopes it to TikTok or Instagram. The concept of 'lookalike' clearly sets it apart from generic creator search among the sibling tools, even though it doesn't name a specific sibling.
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 an explicit trigger: 'Use when one creator already fits and you want more of the same.' This is clear context, but it does not mention when not to use it or name alternative tools, stopping short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that nothing is fetched and there is no cost, and that only the handle is stored. This is useful behavioral context beyond idempotentHint and destructiveHint. It does not contradict any 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 short, front-loaded, and easy to parse. There is minor redundancy with 'no cost' appearing twice, but it does not harm clarity.
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 add-to-watchlist tool, the description covers the core behavior, the no-cost aspect, and the appropriate next step. The output schema exists, so return details are not needed. The only slight gap is the ambiguity of 'Stores the handle only' given that note and platform are also accepted parameters.
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%, and the schema already documents all three parameters, so the baseline is 3. The description's 'Stores the handle only' adds some context around the username parameter, but it does not meaningfully clarify note or platform beyond the schema.
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 uses a specific verb and resource: 'Add a creator to your watchlist,' and clarifies that it stores the handle for later review. This clearly distinguishes it from siblings like catch_up_watchlist and unwatch_creator.
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 states the context ('so you can ask later what they have posted since') and explicitly points to catch_up_watchlist as the follow-up tool. It does not enumerate exclusions, but the primary usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context that the tool consumes 3 orchyn credits, which is important for agents managing costs, and also specifies the output structure of the variants.
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 concise and front-loaded with the core purpose, then adds cost and usage context. Minor formatting issue with the missing space after 'credits.Use' is negligible but prevents a perfect score.
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?
Between the description, full schema coverage, annotations, and presence of an output schema, an agent has everything needed to decide when and how to call this tool. It covers cost, output content, and the required post-to-variants workflow.
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 parameters are already documented clearly in the input schema. The description does not add much parameter-level detail beyond that, staying at the baseline for high schema coverage.
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 clearly identifies the action: turning an analyzed post into filmable variants, with a specific outcome (hook, angle, shot beats, CTA). It differentiates from sibling tools like analyze_post by moving from 'why it worked' to 'what to make.'
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 states when to use the tool: 'Use after analysing a post,' and explains the transition from analysis to creation. It does not explicitly name alternatives or say when not to use it, but the sequencing is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations: it consumes 2 orchyn credits, includes free credits for new users, supports TikTok/Instagram, and explains the virality significance of sounds. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. A minor formatting issue ('credits).Use') is present, but otherwise every sentence contributes meaningful context: purpose, returns, cost, and usage guidance.
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?
The description covers purpose, platforms, return contents, cost, and when to use it. Since the schema and output schema already handle parameter and return-structure details, nothing essential is missing for an agent to call this tool correctly.
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 parameter meanings are already fully documented. The description adds thematic context ('trending', 'before it peaks') but does not add new details about count, platform defaults, or keyword formatting beyond what the schema already provides.
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 uses a specific verb ('discover') and a concrete resource ('trending sounds/music for a keyword on TikTok or Instagram'), and it lists the returned fields. This clearly distinguishes it from sibling tools like discover_hashtags or discover_social_posts.
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 gives explicit use cases: 'when picking audio for a post, or to spot a sound before it peaks.' It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, which cover the read-only behavior. The description adds a valuable behavioral detail beyond annotations: 'Consumes 2 orchyn credits,' which is important for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the tool's function and output format; the second adds the credit cost and the intended use case. Every sentence contributes essential information.
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 read-only analysis tool with a complete input schema, an output schema, and read-only/idempotent annotations, this description is sufficient. It explains what the tool produces, what it consumes, and when to use it, so an agent can select and invoke it correctly.
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%: username, limit, and platform each have descriptions in the schema. The tool description does not add parameter-level detail, but it doesn't need to because the schema already fully documents the parameters. Baseline 3 is appropriate.
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 names a specific action ('Extract') and a specific resource ('a creator's repeatable formula'), and defines the concrete output: fill-in-the-blank templates another creator could adapt. This clearly separates it from siblings like write_hooks or analyze_post by focusing on reverse-engineering a creator's pattern rather than creating or analyzing a single post.
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 explicitly tells the agent when to use the tool: 'Use to reverse-engineer a creator you want to learn from.' This provides clear context for invocation, though it does not explicitly name sibling alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context beyond those annotations: the 2-credit cost, the free-credit note, and the conditional 'when available' behavior for keyword clusters from TikTok Analytics.
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 compact and front-loaded with the core action and resource. Cost and usage guidance each earn their place. The first sentence is slightly overstuffed and 'audience sentiment/audience-signal analysis' is somewhat redundant, preventing a perfect score.
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 read-only, two-parameter fetch tool with an output schema, the description covers purpose, platforms, cost, and alternative routing. It could be slightly more complete about behavior like pagination or output shape, but the output schema and limit parameter mitigate those gaps.
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%: both 'url' and 'limit' are already well documented in the schema, including the default of 20. The description adds platform context but does not meaningfully expand on parameter format, range, or constraints beyond what the schema provides.
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 uses a specific verb ('Fetch'), a clear resource ('top comments for a post URL'), and enumerates all supported platforms. It also distinguishes itself from analyze_comments and other siblings by describing the additional keyword cluster output.
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 explicitly states when to use this tool ('when you want to read what people actually wrote') and when to use the alternative ('use analyze_comments when you want it synthesised into what to do next'). This gives an agent a clear selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the tool uses multimodal AI over actual video/images, includes the thumbnail, supports a list of platforms, and has a metered credit cost (1 free use, then 6 credits). It could mention auth or side effects, but the operation is clearly analytic and read-only in intent.
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 dense but each sentence earns its place: core action, supported platforms, cost, and when-to-use guidance. It is slightly long and could be tightened, but there is no wasted filler.
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 there is no output schema, the description appropriately enumerates what the tool returns. It also covers supported platforms, credit cost, and the strategic alternative. It does not explain error behavior or how the focus parameter interacts, but the schema covers the parameter and the tool's purpose is sufficiently complete.
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 describes both parameters: url as a full public post URL and focus as an extra instruction. Schema coverage is high, so the baseline applies. The description adds context about the analysis but does not add real per-parameter semantics beyond the schema.
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 states a specific verb+resource: import a social post URL and understand it with multimodal AI over the actual video/images. It also lists concrete outputs (summary, hook strength, viral triggers, format breakdown, variation ideas) and explicitly distinguishes itself from analyze_post, the sibling focused on strategy.
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?
It explicitly says 'Use when you need a factual description of what physically happens on screen' and names the better default alternative: 'analyze_post is the better default for strategy.' This gives an agent a clear selection rule against at least one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only, idempotent operation, so the description adds value by explaining the actual workflow: importing media, analyzing video frames/carousel images/caption, and returning the full analysis. The credit cost detail is also behaviorally relevant. It does not detail potential failure modes or long-running behavior, but this is not a significant gap.
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 reasonably concise and front-loaded with the core purpose. It covers platforms, return behavior, cost, and usage guidance without excessive fluff. Minor structural awkwardness exists in the first long sentence, but every sentence earns its place.
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 single-parameter tool with a rich output schema and safety annotations, the description covers all essential context: what is analyzed, which platforms are supported, when to prefer this tool, and the credit cost. An agent has enough information to select and invoke the tool correctly.
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 provides 100% coverage for the single `url` parameter, including the supported platforms. The description adds the media-type nuance (video, image, carousel/slideshow) and explains that the linked content is imported, but the schema already carries most of the parameter meaning.
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 states a specific verb and resource: 'Analyze a social post (video, image, carousel/slideshow) from its link.' It explicitly lists the media types and supported platforms, and differentiates itself from analyze_post_fast by noting that this tool focuses on visuals while the fast version handles script/hook/structure.
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 provides clear when-to-use guidance: 'Use when the visuals are the point.' It also names the alternative tool (analyze_post_fast) and gives a cost-based reason for choosing that alternative, making the selection decision explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, idempotent profile, and the description adds useful operational context beyond them: the call is free and can be made anytime without worry. The description is fully consistent with readOnlyHint=true and adds no contradiction.
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 purpose is front-loaded in the first sentence and the cost/usage guidance is dense and useful. However, there is minor redundancy between 'before running other tools' and 'before a run of paid calls', plus a missing space after 'tools.Use', which reduces polish.
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 zero-parameter, read-only tool with an output schema present, the description covers everything an agent needs: what the tool checks, that it is free, and exactly when to invoke it. No critical information is missing.
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?
The tool has zero parameters and a 100% schema-coverage empty input schema, so the baseline of 4 applies. The description adds useful context about what the response reports (credit balance, billing URL, pack size), which compensates for the lack of a parameterized interface.
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?
Clearly states the resources the tool acts on (credit balance, billing URL, pack size) and uses a specific read-only verb, 'check', which distinguishes it from the sibling buy_orchyn_credits. An agent knows exactly what this does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to call: anytime, and specifically before a run of paid calls to confirm balance coverage. It also removes cost hesitation by stating the call is free. It does not name an explicit when-not or point to the sibling buy tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses that the snapshot is moved forward (a state-changing side effect), that the first run only records a baseline, and that each creator checked consumes 2 orchyn credits. These are important behavioral traits the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core purpose first, then explains the comparison mechanism, the first-run edge case, and the credit cost. Every sentence earns its place with no redundant wording.
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 presence of an output schema and annotations, the description fully covers the tool's scope, stateful behavior, edge cases, and cost. The agent has enough information to decide when to call it and what to expect.
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 describes both parameters with 100% coverage, including defaults and meaning. The description adds general context about per-creator checking but does not substantially enrich the parameter semantics beyond what the schema provides.
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 clearly identifies the verb and resource: fetching recent posts from watched creators, comparing them against a snapshot, and advancing the snapshot. It explicitly distinguishes the tool from 'what exists' queries by framing it as 'what is new', which separates it from sibling tools like get_user_posts or discover_social_posts.
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 provides clear usage context: use this when you want to catch up on new content since the last check, and it explains the first-run baseline behavior. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds important behavioral context beyond annotations by disclosing that the tool 'Consumes 3 orchyn credits,' which is essential for cost-aware tool selection. It also conveys that the report is market-level and current ('right now'), complementing the openWorldHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core value proposition, the cost, and the usage context with zero filler. The most important information is front-loaded, and every sentence earns its place.
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?
The description is complete for practical use: it states what the tool returns, when to use it, what to avoid using it for, and its credit cost. An output schema exists, so return-value details are handled structurally. Annotations cover safety and mutability. No significant context is missing.
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 covers 100% of parameters with descriptions ('Posts to survey', 'Niche or topic', 'Platform to survey'), so the baseline is 3. The tool description does not add new semantic detail about parameters, but it does imply that 'niche' is the central input and that the report is survey-based, which weakly reinforces the schema without going beyond it.
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 clearly identifies the tool's purpose: surveying what works in a niche (formats, hooks, over/underperformance, gaps) and recommending what to make next. It also distinguishes itself from tools that analyze a single post by saying 'rather than judging one post,' which differentiates it from siblings like analyze_post and analyze_creator_profile.
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 explicitly states when to use the tool: 'Use when entering a niche or deciding what to make next.' It also provides a clear exclusion: 'rather than judging one post,' signaling that post-level analysis tools are the alternative. This gives the agent actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds a concrete operational detail not in the annotations: 'Consumes 2 orchyn credits.' This is useful context beyond what the structured metadata provides. There is no contradiction between the description and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no wasted content. It front-lines the core action, then gives the usage condition and cost. Every sentence earns its place.
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 small parameter set, high schema coverage, and presence of an output schema, the description covers purpose, target formats, cost, and the exact use case. Nothing critical is missing for an agent to select and call 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%, and the schema already documents `url` and `targets`. The description adds meaning by enumerating concrete target surfaces (X thread, LinkedIn, carousel, YouTube, newsletter), helping the agent know valid `targets` values even though no formal enum is provided.
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 states a specific verb ('rewrite'), a clear resource ('one post'), and the exact outputs ('X thread, LinkedIn post, carousel slides, YouTube title/description, newsletter'). This makes the tool's purpose immediately distinct from analysis and discovery 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?
The description gives an explicit when-to-use condition: 'Use when a post already worked and you want it on other surfaces.' It does not name alternatives or state when-not-to-use, so it misses the full exclusion guidance but still provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it discloses that the tool consumes 2 orchyn credits and outlines what the response will contain (scores, fixes, rewritten hook, tightened draft). The read-only, idempotent, non-destructive annotations are consistent with this being a review-only operation. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all the essential information: what the tool does, what it returns, its cost, and the best time to use it. The purpose is front-loaded before cost and usage timing. Every sentence earns its place with zero filler.
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 simple two-parameter tool with a single required string, the description is complete: it covers when to use, what it does, cost, and expected outputs. The presence of an output schema means detailed return-value documentation is unnecessary. The only minor omission is elaboration on the platform parameter, but the schema already documents its default.
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's mention of 'film or post' aligns with the draft parameter but adds no new detail about the platform parameter or the draft format beyond what the schema already provides. It does not compensate further for parameter semantics.
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 states a specific action ('Review your own draft') and resource (your draft), then enumerates the concrete outputs: hook strength, clarity and payoff scores, concrete fixes, a rewritten hook, and a tightened draft. The phrase 'your own draft' and 'BEFORE you film or post it' clearly distinguishes it from sibling tools that analyze existing posts or generate hooks.
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 gives explicit timing guidance: 'Use before filming, while changing it is still cheap.' This tells the agent when the tool is appropriate, and the self-draft scope implicitly distinguishes it from analyzing others' posts. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 meaningful behavior beyond annotations: it returns an inline thumbnail image and consumes 1 orchyn credit with a free-credit allowance for new users.
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 appropriately compact and front-loaded with the core purpose and output. It packs platform list, return fields, thumbnail behavior, credit cost, and usage guidance into a short space; a minor formatting issue is the missing space after 'new users).Use'.
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 has only one parameter, a high-coverage schema, an output schema, and strong annotations, the description covers all necessary decision points: supported platforms, returned data, credit cost, and when to choose the sibling tool. No critical guidance is missing.
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?
The schema fully documents the single url parameter, so the baseline is 3. The description adds value by specifying the accepted platform URL types (TikTok, Instagram, YouTube, X/Twitter, Douyin, Xiaohongshu, Bilibili), which helps an agent validate acceptable inputs.
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 names the specific action ('Fetch a social post's media') and the exact resource (post URLs from seven named platforms), and itemizes the returned fields. It also distinguishes itself from the sibling analyze_post_fast by framing itself as returning raw facts and media, not interpretation.
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 explicitly states when to use the tool: 'Use when you need the post's facts and media and nothing more'. It also names the alternative, analyze_post_fast, for interpreted results, giving an agent a clear routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behavioral traits: it fetches recent posts, runs multimodal AI on up to 3, synthesizes a profile report, and costs 1 free use then 15 credits per use. This is exactly the kind of context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: purpose, platforms, workflow, report contents, pricing, and sibling alternative. It front-loads the core purpose before supporting details.
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 complex multi-platform analysis tool, the description covers the workflow, output scope, analysis limits, cost model, and the key alternative. An output schema exists, so return-value details are not required in the description. Nothing critical is missing for an agent to decide whether and how to invoke 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 four parameters, including default values and the 'first 3 analyzed' behavior of limit. The description adds no parameter-level meaning beyond the schema, so baseline 3 is appropriate.
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 names a specific verb ('Deep-dive') and resource ('a whole creator profile') across eight platforms, and enumerates the concrete workflow and report outputs. It also contrasts itself with find_hook_pattern, making sibling differentiation clear.
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?
It explicitly states when to use this tool ('Use for a full teardown when the visuals matter') and names a cheaper alternative for a narrower job ('find_hook_pattern gives you their formula from captions for a fraction of the price'). This gives an agent actionable routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already convey read-only, idempotent, and non-destructive behavior, the description adds meaningful behavioral context: it consumes 2 orchyn credits, costs one-third as much as the alternative, relies on transcript/caption/stats rather than video frames, and has specific quality strengths/weaknesses. These are not derivable from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the key differentiation, adds the cost, and ends with explicit default/alternative guidance. Each sentence earns its place; the only minor flaw is a missing space after 'credits.'
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 single-parameter tool with an output schema, annotations, and an explicit alternative, this description is complete. It covers what the tool does, how it differs, what it costs, when to use it, and when not to use it. An agent has everything needed to decide whether to invoke 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?
There is only one parameter, url, and the schema already describes it fully as 'Full public post URL.' The description adds useful context about the source content (transcript, caption, stats), but does not add new parameter-specific semantics beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
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 clearly states that this performs the same analysis as analyze_post but from transcript, caption, and stats rather than video frames, and explicitly names the differentiate-from sibling. The verb and resource are specific, and an agent can immediately tell this tool apart from analyze_post.
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?
It gives explicit routing guidance: 'Use this by default; reach for analyze_post when the visuals are the point.' It also describes the tradeoff between visual-style weakness and strength on hook, script, CTA, and audience, which helps an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), the description discloses key behavioral details: the call itself costs nothing, it returns a Stripe checkout URL that the user must open in a browser, and credits are added automatically after payment. This explains the external payment flow and separates 'calling the tool' from 'paying,' which is valuable context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: 'Buy an MCP credit pack via Stripe Checkout' immediately states the action. Three short sentences cover the return value, payment flow, automatic credit addition, cost, and usage condition, with no filler or redundancy.
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 zero-parameter tool with an output schema, the description is complete: it explains the return URL, the browser step, the automatic credit addition, the credit cost, and when to call the tool. An agent has everything needed to invoke it correctly without further ambiguity.
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?
There are zero parameters, so the schema naturally has 100% coverage and no parameter-level documentation is needed. The description adds context about what the tool returns and how the operation works, which is more than enough for a parameterless tool. No parameter gaps exist to compensate for.
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 states a specific verb and resource: 'Buy an MCP credit pack via Stripe Checkout.' It also explains the operational outcome (returns a secure checkout URL), which clearly distinguishes it from siblings like check_orchyn_credits that check balance. The title and description align, and the purpose is unmistakable.
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 gives an explicit when-to-use condition: 'Use when the balance is short and the user has agreed to top up.' This provides clear situational context and a user-consent gate. It does not name alternatives or state when not to use it, but the condition itself is sufficient for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly and idempotent behavior, and the description adds valuable context: it consumes 1 orchyn credit, returns plain text with a word count, and provides an available:false response with a reason when no captions exist. This goes beyond the structured annotations and gives the agent clear expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is purposeful and the description is front-loaded with the core function, followed by usage guidance, return behavior, and cost. The only minor flaw is a missing space in 'credit.Use', but overall it is tight and well structured.
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 low-complexity read-only tool with an output schema and full schema parameter coverage, the description fully covers what the tool does, when to use it, what to expect as output, and the cost of invoking it. No critical operational detail is missing.
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 does not add meaningful parameter-level detail beyond what the schema already provides for 'url' and 'language'.
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 states a specific action ('Get the words actually spoken'), identifies the resource (caption track of TikTok or YouTube posts), and explicitly differentiates from analyze_post by emphasizing verbatim transcript over interpretation. This makes the tool's purpose immediately distinguishable from siblings.
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?
'Use this before analyze_post when you need the script, hook wording or CTA verbatim rather than an interpretation' directly tells the agent when to choose this tool over a clear alternative. 'Use before any analysis when the exact wording matters' further reinforces the decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond those annotations: the tool returns a fresh login URL, costs nothing to call, and re-links the account. This is sufficient for a zero-parameter auth helper.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the purpose, and every sentence earns its place. There is a minor missing space after 'call.' but the structure is otherwise exemplary.
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 zero-parameter tool with an output schema and clear annotations, the description is complete. It tells the agent what the tool does, when to use it, and what to expect, leaving no critical gaps.
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?
The tool has zero parameters and the schema is fully documented by default, so the baseline of 4 applies. The description does not need to explain parameter meaning.
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 states a specific verb ('Get') and resource ('fresh login URL') and clearly explains the purpose: re-authenticating an MCP session. It is immediately distinguishable from all sibling tools, none of which involve authentication or login.
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?
Explicitly tells the agent when to call it: when the session has expired, when reconnection is needed, and when calls fail with an authentication error. This removes ambiguity and provides actionable trigger conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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, so the description adds complementary behavioral details: it discloses credit consumption ('Consumes 2 orchyn credits'), explains the returned fields (title/caption, thumbnailUrl, externalUrl, stats, up to 4 inline thumbnails), and notes that thumbnails render in chat. No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence contributes: purpose, output contents, when to use, credit cost, and the alternative tool. It is front-loaded with the core purpose and ends with the sibling routing; no filler or repetition beyond the slight overlap between 'Use this when...' and 'Use to scan...'.
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 read-only listing tool with an output schema and thorough annotations, the description covers all essential operational context: platform list, handle example, return contents, credit cost, and the precise differentiation from find_hook_pattern. Nothing an agent needs to decide to call this tool correctly is missing.
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?
The schema already covers all three parameters with descriptions, so the baseline is 3. The description adds useful semantic nuance beyond the schema, especially the LinkedIn public_id rule and the '@' prefix tolerance for creator handles, which reduces the chance of incorrect parameter values.
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: 'List recent posts by a creator handle', and enumerates the supported platforms with concrete examples like '@zoundsapp' and LinkedIn's 'williamhgates'. It also differentiates itself from find_hook_pattern by clarifying that this tool returns the raw list rather than an extracted formula.
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 states exact use cases: 'Use this when Claude needs to pull more posts from the same account to spot a pattern, or to scan a whole profile.' It also explicitly directs to find_hook_pattern when the goal is extracting the creator's formula, providing a clear when-not-to-use alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, so the description adds non-overlapping context: it costs 2 orchyn credits, supports pagination via offset, and returns inline thumbnails intended to render in chat. These are behavioral details not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet efficient: every sentence contributes something — scope, result contents, chat behavior, pagination, batch analysis, sibling differentiation, and cost. It is front-loaded with the core purpose before diving into secondary details.
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 rich annotations and output schema, the description fills all remaining practical gaps: when to choose an alternative, credit cost, pagination command, and chat-oriented output behavior. An agent has everything needed to 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 the baseline is 3, but the description adds practical meaning beyond the schema by linking offset to the 'next' command, giving concrete niche examples, and explaining how the returned posts are meant to be used. This helps an agent reason about limit, platform, and pagination choices.
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-resource pair: discovering recent posts for a niche across named platforms and content types. It explicitly contrasts itself with niche_report, so an agent can immediately tell what this tool returns versus what it does not.
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?
It explicitly states when to use this tool (find individual posts to look at) and when to prefer niche_report (pattern across posts). It also documents interaction patterns like saying 'next' for pagination and 'analyze the 2nd one' / 'analyze all' for batch analysis, making usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nooticr-mcp MCP server](https://glama.ai/mcp/servers/orchynX/nooticr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/orchynX/nooticr-mcp)

Score Badge

Copy to your README.md:

[![nooticr-mcp MCP server](https://glama.ai/mcp/servers/orchynX/nooticr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/orchynX/nooticr-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/orchynX/nooticr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server