re-ios

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation4/5
Most tools have clear distinct purposes, but there is some overlap: three tools for checking encryption (check_encryption, check_macho_encryption, dynamic_check_cryptid) with subtle differences, and analyze_macho_objc/analyze_macho_objc_deep are nearly identical. Descriptions help differentiate but boundaries could be clearer.
Naming Consistency4/5
Tools follow a mostly consistent verb_noun snake_case pattern (e.g., analyze_, check_, dynamic_, frida_). However, there are deviations like 'trollstore_guide' (noun_noun), 'run_skill_pipeline' (verb_verb_noun?), and some mixing of prefixes (e.g., dynamic_check vs check). Overall decent but not perfectly uniform.
Tool Count3/5
With 32 tools, the server is on the heavier side. While the domain of iOS reverse engineering is broad and warrants many tools, some functionality is duplicated (e.g., three encryption checks) and a few tools could be merged. The count is reasonable but borderline high.
Completeness4/5
The tool set covers the main iOS reverse engineering workflow: static analysis, dynamic hooking, device management, IPA manipulation, and reporting. Minor gaps like specific hooking for other frameworks or advanced patching are missing, but core functionality is well-represented.
Average 3.5/5 across 32 of 32 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It states 'verify' but does not clarify whether the tool is read-only or if it modifies files. The name implies fixing, so the behavioral expectation is unclear.
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 very short, with an 'Args' section that is efficient. However, it lacks any explanation of return values or side effects, which would be valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the potential for destructive action (implied by 'fix'), the description is incomplete. It does not explain what happens on mismatch, what the return value indicates, or how to interpret results.
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 0%, so the description must compensate. It adds 'Path to .app bundle' for the single parameter, which is a minor clarification over the schema title 'App Dir'. This is insufficient for a parameter that likely requires validation.
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 action: 'Verify icon references in Info.plist match actual files in .app bundle.' This clearly identifies the tool's purpose, though the tool name 'fix_app_icons' suggests a repair action, creating a slight mismatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'check_ios' or 'full_analysis'. There are no prerequisites, exclusions, or contextual hints for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It only states the enumeration action, not whether it's read-only or destructive, nor any behavioral traits like output format or limitations. This is insufficient for an agent to understand side effects.
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 very short and efficient, with no unnecessary words. It clearly separates the main description from the parameter definition. However, it could benefit from a structured format like bullet points for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description should explain the return format (e.g., list of framework names) and how it differs from related tools. It is minimal and leaves the agent guessing about what the output looks like.
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?
With 0% schema description coverage, the description adds the fact that 'path' is a path to a Mach-O binary, which provides basic meaning beyond the schema's type-only definition. However, it lacks details like absolute/relative path requirements, valid file extensions, or error cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates linked frameworks/libraries from a Mach-O binary, which is a specific verb-resource pair. It implicitly distinguishes from sibling tools that analyze other aspects like architectures (analyze_macho_archs) or Objective-C (analyze_macho_objc). However, no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools for Mach-O analysis, the description should indicate scenarios or prerequisites, but it fails to do so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action without disclosing side effects, permissions required, input validation, or error behavior. For example, it doesn't indicate if the tool modifies files or requires special access.
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 very brief (two sentences) and front-loads the purpose. It could benefit from a clearer structure (e.g., bullet points), but there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too minimal. It lacks details about the return format, error handling, or any contextual prerequisites (e.g., whether the file must be uncompressed). An agent would be underinformed.
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 description adds modest meaning beyond the schema: it specifies the path parameter as 'Path to IPA file or .app bundle'. However, schema coverage is 0%, and the description does not elaborate on format requirements or constraints, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'extract' and the resource 'entitlements' from an 'IPA file or .app bundle'. It provides a specific purpose that distinguishes it from sibling tools like `full_analysis`, though it doesn't explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred (e.g., over `full_analysis`).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It only mentions using 'lipo' but does not disclose side effects, permissions, or limitations beyond being a read-only operation.
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 extremely concise with two clear sentences, no fluff, and front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description fails to clarify return values (e.g., list of architecture strings), leaving a critical gap for effective tool usage.
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?
With 0% schema description coverage, the description must add meaning beyond the schema. It merely restates 'path: Path to a Mach-O binary', adding minimal context without clarifying format or constraints.
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 explicitly states 'List architectures in a Mach-O binary' with a clear verb and resource, and it effectively distinguishes from sibling tools like analyze_linked_frameworks and analyze_macho_objc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It reveals the use of 'nm + strings' but omits critical details such as output format (e.g., dump format, class listing depth), whether it works on all Mach-O binaries, error behavior, or performance characteristics. The lack of annotations amplifies these gaps.
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, using two short sentences to convey purpose and the single parameter. It is front-loaded and avoids unnecessary words. However, it could benefit from a brief sentence on output or limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter, no nested objects), the description lacks essential context: no output specification, no mention of what 'dump' means (list of strings? structured JSON?), no error conditions, and no prerequisites. Annotations would help but are absent.
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 has only one parameter 'path' with 0% description coverage, so the description is the sole documentation. It adds basic context: 'Path to a Mach-O binary', which clarifies what the path should point to. However, it does not specify file requirements (e.g., must be executable, fat vs thin).
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 the tool's purpose: 'Dump Objective-C classes from a Mach-O binary using static analysis (nm + strings).' It specifies a concrete action, resource, and technique, and it distinguishes itself from sibling tools like analyze_swift_symbols and analyze_macho_objc_deep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as analyze_macho_objc_deep or analyze_swift_symbols. It does not mention prerequisites, limitations (e.g., encrypted binaries), or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only says 'report', implying read-only, but does not confirm side effects, idempotency, or permission requirements.
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 a single, concise sentence that front-loads the purpose. It is efficient but may be too minimal for full context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and no output schema, the description is adequate but lacks detail on what 'capabilities' include or how the report is structured, which could be important for an agent.
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 no parameters, so the schema already provides full coverage. The description does not need to add parameter meaning, earning a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports server status and available capabilities, which distinguishes it from sibling tools that focus on specific analysis tasks. However, 'capabilities' could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as before running other tools or to check prerequisites. The description lacks context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not specify return type (e.g., boolean), whether it is read-only, or any side effects. The description is insufficient for an agent to understand behavior beyond the basic action.
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 brief and front-loaded: the first sentence conveys the purpose, followed by a clear parameter listing. It avoids unnecessary words, but could additionally specify return value in the same concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is incomplete. It fails to mention the return value (e.g., boolean) and any behavioral traits like read-only nature. An agent cannot fully anticipate the tool's output.
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 description's 'Args' section adds minimal semantic information over the schema: it specifies the path must point to a Mach-O binary. However, schema coverage is 0% (no param descriptions), so the description provides the only explanation. This is adequate for a single required parameter.
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 the action ('Check if') and the target ('Mach-O binary is encrypted'), specifying FairPlay DRM, which distinctively separates it from sibling tools like 'check_encryption' and 'dynamic_check_cryptid'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'check_encryption' (likely for general encryption checking) or 'dynamic_check_cryptid'. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool generates a report but doesn't reveal side effects, required permissions, return format, or what happens with invalid input. The description is minimal beyond input specification.
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 with a single introductory sentence and a structured Args list front-loading the purpose. No unnecessary information, but the Arg list adds slight verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description explains inputs adequately but lacks details about the output format, return value, or error handling. It is minimally complete for a report-generation tool.
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 description provides clear explanations for both parameters (path to IPA/Mach-O, optional analysis_dir for endpoint scanning), which are absent from the input schema (0% schema coverage). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a human-readable analysis report from an IPA or analysis directory, specifying the verb (generate) and resource (report). However, it doesn't distinguish from sibling tools like full_analysis, which may produce similar reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether an analysis must be run first, or exclude cases like when a specific analysis tool (e.g., analyze_linked_frameworks) is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool attaches to a running app and reads Mach-O headers, implying process injection and potential side effects. However, it does not mention whether the app is killed or resumed, or if special permissions (jailbreak, developer mode) are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, with the first sentence stating the purpose and the second adding technical detail. It is well-structured but could be more concise by avoiding repetition (e.g., 'Attaches to the running app' is implied by 'at runtime').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (runtime process attachment, reading headers), the description lacks important details: it does not specify return value (boolean?), side effects (app state after check), or prerequisites. Since there is no output schema, the return type should be described. The description is incomplete for an agent to fully understand the tool's behavior.
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 input schema has one required parameter (bundle_id) with only a title. The description adds meaning by specifying 'Bundle identifier of the target app', clarifying the expected format. With 0% schema description coverage, the description effectively compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an app is encrypted using FairPlay DRM by reading cryptid at runtime. The verb 'check' and resource 'app encryption' are specific. However, it does not explicitly distinguish from siblings like 'check_macho_encryption' or 'dynamic_check_cryptid', which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., app must be running), or when not to use it (e.g., if the app is not running or if static analysis is desired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It notes recursive scanning of text files but misses details on output format, whether it's read-only, permissions required, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no unnecessary words. Uses 'Args:' formatting but remains concise. The description is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, description covers the core purpose. However, it lacks output format or error details, making it adequate but not fully 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?
Only one parameter (analysis_dir) with schema type 'string' but no schema description. Description adds 'Path to the analysis directory', providing basic meaning. With low schema coverage (0%), this is adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('scan') and resource ('analysis directory') and specifies what it finds (hardcoded URLs, domains, API paths). It distinguishes itself from sibling tools like analyze_linked_frameworks or analyze_macho_archs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (siblings listed but no contrast). Implies use for network endpoint clues but lacks explicit when-to or when-not-to instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions fallback behavior but does not disclose prerequisites, potential failures if class-dump is unavailable, or whether the tool is read-only. It lacks detail on side effects or dependencies.
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 extremely concise: two sentences covering the core function and the argument. Every word is necessary with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deep ObjC analysis) and lack of output schema, the description is incomplete. It does not explain what the output contains, how to interpret results, or the meaning of 'deep'. For a nuanced tool, more details are expected.
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 description adds 'Path to a Mach-O binary' for the path parameter, providing context beyond the schema's type and title. However, the schema already specifies it as a string with title 'Path', so the added value is marginal. With 0% schema description coverage, this is adequate but not exceptional.
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 it performs a deep Objective-C class dump, specifying the method (class-dump with fallback to nm+strings). This distinguishes it from the sibling analyze_macho_objc (likely a basic analysis) and other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deep ObjC analysis but does not provide explicit guidance on when not to use it or alternatives like analyze_macho_objc for simpler needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on side effects, preconditions (e.g., app must be running, jailbreak required), or reversibility. The behavior beyond basic injection (e.g., how to stop monitoring, impact on app) is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the core action and then detailing parameters. It uses a clear bullet-point style without redundant information, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description moderately covers the tool's purpose and parameters. However, it lacks information about return values (e.g., logs, output format) and overall behavior, leaving some gaps for a safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: target (bundle ID or PID), device_type (with allowed values), device_id (optional), and duration (in seconds). This adds significant meaning beyond the bare 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 clearly states the tool injects a network interception hook into a running iOS app, listing specific APIs (NSURLSession, CFNetwork, etc.). This distinguishes it from siblings like dynamic_hook_iap which targets in-app purchases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It simply describes the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the full workflow (extract, replace, modify, sign, repackage) and mentions signing tools (ldid/codesign). However, no annotations are provided, and the description does not disclose potential side effects, error conditions, or required permissions.
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 well-structured: a one-line summary, bulleted workflow, then argument list. It is moderately sized and front-loaded, though could be slightly more concise.
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 8 parameters (1 required) and no output schema, the description covers the workflow and all parameters adequately. It explains the tool's operation sufficiently for an agent to use it 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?
With 0% schema description coverage, the description compensates by listing all parameters with clear explanations (e.g., 'input_path: Path to .ipa or .app bundle to resign'). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resigning IPA or .app bundles with new identity and metadata. It uses specific verbs and resources, but does not differentiate from sibling tools like resign_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for use. The description lacks context about 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full burden. It mentions Frida but fails to disclose prerequisites (Frida server, debugger, root), potential side effects (app interruption), or whether it modifies state. Behavioral traits like requiring USB connection are only implied via parameters.
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?
Description is front-loaded with purpose and method, followed by parameter details. Each sentence contributes value, though the args section mirrors documentation style. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and absence of annotations, description lacks critical information about return format (list of modules? cryptid values?) and prerequisites (Frida server on device). This leaves significant gaps for an agent to invoke 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 0%, so description compensates well by explaining target as bundle ID, device_type with allowed values and default, and device_id as optional. Adds meaning beyond schema but could include format or constraints for device_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks encryption status (cryptid) of loaded Mach-O binaries at runtime, using a specific verb and resource. It distinguishes from static analysis siblings like 'check_encryption' by emphasizing runtime behavior (Frida enumeration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies runtime usage with Frida but does not explicitly state when to use this tool over static alternatives. No exclusion criteria or alternative tool names are provided, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention that the tool likely requires a USB connection or network access to a device, nor does it state safety (e.g., read-only operation) or any side effects. The agent cannot infer these traits.
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?
Extremely concise: a one-sentence purpose followed by a clean parameter list. No extraneous information, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is adequate but incomplete. It does not describe the return value format (e.g., device properties like name, model, OS) which would help the agent interpret results.
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 description adds meaning beyond the input schema by listing valid values for device_type ('usb', 'local', or 'remote') and clarifying device_id as 'Specific device ID (optional)'. Schema coverage is 0%, so this compensation is valuable, though not exhaustive.
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 'Get detailed info about a Frida device' with a specific verb ('Get') and resource ('Frida device'). It distinguishes from siblings like frida_list_devices (list devices) and frida_list_processes (list processes) by focusing on detailed info for a single device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like frida_list_devices or frida_find_process. The description does not mention prerequisites, when not to use it, or compare with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It explains parameters but does not mention what the tool returns (e.g., process ID, name) or what happens if the target is not found. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses a clear args list format without extraneous text. Every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the purpose and parameters adequately. However, it lacks information on return values and error cases, which would be helpful for a complete understanding.
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 description coverage is 0%, so the description carries full burden. It explains 'target' as process name, PID, or bundle ID, and gives defaults for 'device_type' and 'device_id'. This adds meaningful context beyond the raw 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 clearly states the action 'Find a process' and the resources (name, PID, or bundle identifier). It distinguishes from sibling tools like frida_list_processes which lists all processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like frida_list_processes for listing all processes. The description does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'List all available Frida devices' without explaining side effects (none likely), performance characteristics, or what happens if devices are not found. For a simple read operation, the description is too terse.
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 a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description provides the core purpose but omits details like what information is returned (e.g., device IDs, types, statuses). For a tool that lists devices, the agent might benefit from knowing whether it returns a list of strings or a structured object. The description is minimally adequate.
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 schema coverage is 100% (vacuously). According to rubric, 0 parameters yields a baseline of 4. The description adds no parameter information, but none is needed. The score reflects that the description does not add value beyond the schema, but the schema covers all.
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 the tool's purpose: 'List all available Frida devices (USB, local, remote).' It uses a specific verb ('List') and identifies the resource ('all available Frida devices') with qualifiers that distinguish it from sibling tools like frida_device_info or frida_find_process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or common use cases. Ideally, it should suggest using this tool to discover devices before connecting or targeting a specific process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It does not disclose side effects, permissions needed, or whether the operation is read-only. The description lacks detail beyond 'extract full metadata'.
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 concise sentences: first states purpose, second lists argument with context. No redundant text, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should describe return values or side effects. It only mentions 'full metadata' without specifics, which is a gap for a complex extraction tool. Adequate for a simple tool but incomplete.
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 description adds meaning to the single parameter 'path' by specifying it can be a .app bundle, which is not in the schema. With only one parameter, the description compensates for the 0% 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 states the verb 'Parse', the resource 'IPA file', and the output 'full metadata' including specific elements. This distinguishes it from sibling tools that focus on sub-analyses (e.g., analyze_linked_frameworks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings. The description does not mention preconditions, exclusions, or alternative tools for specific filtering needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states 'Kill' which implies destructive action, but lacks details on side effects, requirements (e.g., Frida server running), or behavior on invalid PIDs.
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 concise and front-loaded, stating the purpose first and then listing arguments. No unnecessary words, every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive action) and absence of output schema, the description is incomplete. It does not explain return values, success/failure indicators, preconditions, or error cases like invalid PID. Siblings are not referenced for comparison.
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 description coverage is 0%, so the description compensates by explaining each parameter: pid as 'Process ID', device_type with possible values and default, device_id as optional. This adds needed context, though it could be more precise (e.g., allowed 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 clearly states 'Kill a process by PID', using a specific verb and resource. This distinguishes it from sibling tools like frida_resume_app or frida_spawn_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as frida_resume or frida_spawn. It only implies the context of killing a process, but lacks prerequisites or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the tool is read-only, modifies the target, or has side effects. The mention of dynamic hooks implies potential runtime interactions, but safety implications are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by a concise bullet list of levels. It is efficient and well-structured, though the parameter details could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the different analysis levels and parameters, but lacks information on the output format, return value, or how the agent can use the results. Given the complexity, more detail on artifacts would improve completeness.
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?
With 0% schema description coverage, the description fully explains all three parameters: target as path or bundle ID, level with explicit allowed values and default, and output_dir with default path. This adds meaning beyond the bare 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 clearly states the tool runs a 'comprehensive analysis pipeline' on an 'iOS target' and enumerates three specific analysis levels, distinguishing it from sibling tools that focus on individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three levels and notes that dynamic requires a device, but does not explicitly advise when to use this tool versus sibling tools like analyze_macho_archs or full_static_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states that results are written to output_dir. It does not disclose side effects (e.g., file creation, modification), environment requirements, or potential destructive operations. Basic pipeline execution is implied but not detailed.
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 well-structured with purpose first, then pipeline steps, then argument list. It is appropriately sized for the tool's complexity, with no wasted words. Minor tightening possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic usage and parameters but lacks output format details, prerequisites, or how results are organized in output_dir. Given no output schema, additional context on result structure would improve completeness.
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 0%, so description adds meaning: target is clarified as 'Path to IPA file, .app bundle, or Mach-O binary' and output_dir has a default value explained. This goes beyond the schema's bare types and provides actionable guidance.
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 'Run the full original SKILL.md static analysis pipeline' and lists the steps (unpack → fingerprint → macho analyze → class scan → api scan → report). This verb+resource combination is specific and distinguishes from sibling tools that perform individual analysis steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool runs the entire pipeline in one go, contrasting with sibling tools that are single steps. However, it does not explicitly state when to use this vs. alternatives, nor does it mention any prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not state that the operation is read-only, whether it requires special permissions, or what happens if the binary has no Swift symbols. The default for max_symbols is noted, but overall transparency is lacking.
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 extremely concise: a single sentence followed by two documented parameters. Every word is necessary, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the core purpose and parameter meanings. However, it lacks information on the return format (e.g., list of demangled symbols) and explicit confirmation of read-only behavior, leaving minor 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?
With 0% schema description coverage, the description compensates by explaining 'path' as 'Path to a Mach-O binary' and 'max_symbols' as 'Maximum number of symbols to demangle (default: 500).' This adds necessary meaning beyond the bare schema properties.
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 'Demangle Swift symbols from a Mach-O binary,' specifying the verb 'demangle' and the resource 'Swift symbols from a Mach-O binary.' This distinguishes it from sibling tools like 'analyze_macho_archs' and 'analyze_macho_objc' that focus on other aspects of Mach-O files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for demangling Swift symbols but does not provide explicit guidance on when to use this tool versus alternatives. It lacks information on prerequisites, when not to use, or specific scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions using Frida to enumerate classes, but does not disclose whether it modifies state, requires permissions, or has any side effects. Basic information is present but incomplete for a comprehensive understanding.
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 extremely concise, with a one-line summary followed by a clear argument list. No unnecessary words, and the structure front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description covers its action and arguments but omits what the tool returns (e.g., a list of class names). Given the absence of output schema, mentioning the output would improve completeness.
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?
With 0% schema description coverage, the description adds meaning to parameters by explaining 'target' is bundle ID or PID, 'device_type' options with default, and 'device_id' as optional. However, it lacks format constraints or enum values, leaving some ambiguity.
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 the tool enumerates Objective-C classes at runtime on a running iOS app using Frida. The verb 'enumerate' and resource 'Objective-C classes' are specific, and it distinguishes from sibling tools which are static or do other dynamic operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and its arguments but does not provide explicit guidance on when to use this tool versus alternatives like static analysis or other dynamic tools. Usage is implied but not clarified with when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains what methods are hooked and what is logged, but lacks disclosure of potential side effects (e.g., app crashes, detection risks, performance impact) or whether the hook is reversible. Does not state if results are printed to console or saved.
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 concise (3 sentences plus an Args block) and front-loaded. Every sentence serves a purpose: what it does, what it hooks, and parameter details. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (hooking a running app), the description lacks explanation of return values or output format (e.g., logs, console output, file). It does not mention cleanup after duration or how to verify hook success. Missing context for a tool that modifies runtime behavior.
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 0%, so description must compensate. It explains all 4 parameters: target (bundle ID or PID), device_type (usb/local/remote), device_id (optional specific device), and duration (monitoring seconds). This adds meaningful context beyond the schema's type-only definitions.
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 'Inject IAP hook into a running iOS app' with specific verbs and resources, and explicitly lists hooked StoreKit methods (SKPaymentQueue, purchase transactions, product requests, receipt validation). This distinguishes it from sibling hook tools like dynamic_hook_network.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., dynamic_hook_network or other analysis tools). The description does not mention prerequisites, scenarios, or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the action (resume) but does not explain what happens if the app is not in a suspendable state, whether the action is reversible, or what the return value indicates (no output schema). Basic info is provided but lacks depth.
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 extremely concise: one sentence for purpose followed by a clear parameter list. Every element earns its place with no redundancy. The purpose is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema and annotations, the description is minimally adequate. It covers the core action and parameters, but missing context—such as the requirement that the app was previously spawned or suspended—hampers full understanding. Some ties to sibling tools would improve completeness.
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 description coverage is 0%, so the description must add parameter meaning. It explains 'pid: Process ID', 'device_type' with allowed values and default 'usb', and 'device_id' as optional. This adds substantial value beyond the schema's type and default fields, though it could be more explicit about how to obtain device IDs.
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 the tool's purpose: 'Resume a spawned/suspended app.' The verb 'Resume' and resource 'app' are specific and distinct from sibling tools like frida_spawn_app and frida_kill_app, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that the app must have been spawned via frida_spawn_app) or when not to use it, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool is a 'check' (suggesting read-only), but does not explicitly confirm safety, side effects, or permissions needed. For a diagnostic tool, more transparency about non-destructive behavior would help.
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 (two sentences) and front-loaded with purpose. Could be slightly more structured (e.g., bullet points for return fields), but no unnecessary words.
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 no output schema, the description adequately describes return values: 'signing method (ldid/codesign/none), available certs, and readiness.' This covers the main outputs for a simple check tool. No significant 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?
There are zero parameters, so the description's job is minimal. It adds value by explaining what the tool examines (tools and identities), which is beyond the empty schema. Baseline 4 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 the tool's purpose: 'Check signing environment: available tools and code signing identities.' This is a specific verb-resource combination, distinguishing it from sibling tools like resign_ipa_tool which performs an actual signing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a diagnostic tool to check readiness before signing, but does not explicitly state when to use it vs alternatives (e.g., when to run before resign_ipa_tool). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool returns a step-by-step workflow reference, with no mention of side effects, permissions, or other 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?
The description is brief (three sentences) and front-loaded with the core purpose. Every sentence adds value: two sentences detail the tools' roles, and one states the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and is a guide. The description states it returns a 'step-by-step workflow reference' but does not specify format (e.g., text, JSON) or content details, leaving some ambiguity for an AI agent.
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 input schema has zero parameters, and schema description coverage is 100%. Per guidelines, no parameter info is needed, so baseline score of 4 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?
The description clearly states the tool's purpose: 'Get the recommended workflow for combining TrollStore (on-device) with re-ios (desktop).' It specifies the verb (get), resource (workflow), and context (combining two tools), distinguishing it from sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the roles of TrollStore and re-ios, implying usage when combining these tools, but does not explicitly state when to use this guide versus alternatives like the many analysis tools listed as siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions requirement and output, but doesn't disclose side effects, error conditions, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences of purpose followed by a requirements note and bullet-point parameters. Well-structured and appropriately sized, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about return values or output format. Given no output schema and 4 params, the description covers purpose and parameters but omits result communication details.
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?
Input schema has 0% coverage but description includes an Args section that explains each parameter's purpose and defaults, adding meaningful context beyond schema titles.
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 it decrypts FairPlay DRM from iOS apps using frida-ios-dump, distinguishing it from sibling tools that perform analysis, resigning, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for encrypted IPAs on tethered devices with frida-ios-dump installed, but lacks explicit 'when-not-to-use' or comparisons with alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions device_type and device_id but does not describe error handling, permission requirements, or behavior when the device is not connected.
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 short and front-loaded with the core purpose, followed by parameter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and no output schema, the description is mostly adequate but does not specify the return format (e.g., process IDs and names). It leaves the agent to infer the output structure.
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?
With 0% schema description coverage, the description adds value by explaining the device_type options ('usb', 'local', 'remote') and the optional device_id. However, it could be more specific (e.g., enum 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 clearly states 'List running processes on a Frida device' with a specific verb ('list') and resource ('processes'). It sufficiently distinguishes from sibling tools like frida_find_process or frida_device_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context is implied but lacks explicit exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic behavior (spawn an iOS app) and parameters, but lacks details on consequences like what happens if the app is already running, required permissions, or whether it returns a process object. Without annotations, more depth would be beneficial.
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 extremely concise: a single-purpose sentence followed by a clear parameter list. No unnecessary words or repetition.
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 tool's simplicity and lack of output schema, the description adequately covers the action and parameters. It does not mention return values or side effects, but this is acceptable for a spawn operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to each parameter: explains bundle_id format with example, device_type options with default, and device_id optionality. This fully compensates for the 0% 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 states the verb 'spawn' and the resource 'iOS app by bundle ID', making the tool's purpose specific and distinct from siblings like frida_kill_app or frida_resume_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It simply describes the action without mentioning prerequisites or situations where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the extraction action and default output directory, but lacks details on error handling, permissions, or side effects.
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 extremely concise, consisting of one sentence and an argument list with no unnecessary words. It is front-loaded and efficient.
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 extraction tool with two parameters and no output schema, the description covers the essentials. However, it could mention the return value or error behavior for completeness.
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 0%, so the description must compensate. It explains the two parameters: 'path' is required, 'output_dir' is optional with a default, providing meaning beyond the schema's type and title.
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 the action: 'Extract an IPA file to a directory for further analysis.' It specifies the verb 'extract' and the resource 'IPA file', clearly distinguishing it from sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a first step before analysis, but does not explicitly state when to use it versus alternatives or provide any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists capabilities (what it analyzes) but does not disclose behavioral traits such as performance, side effects (e.g., it is read-only), or limitations. The description is adequate but minimal in transparency.
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 extremely concise: one line summarizing the purpose, a bullet list of what it combines, and a single parameter description. Every sentence adds value; there is no redundancy or fluff. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently explains the tool's input and actions but lacks any detail about the output or return value. For a tool with no output schema, the description should at least hint at what the analysis result is (e.g., a report or structured data). This incomplete description leaves the agent guessing about the result format.
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 input schema has 0% description coverage, meaning the parameter descriptions rely entirely on the tool description. The description adds meaningful context: it specifies that 'path' must be a path to an IPA file or Mach-O binary, which is beyond the schema's type of string. This compensates well for the lack of schema descriptions.
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 it runs a full static analysis pipeline on an IPA or Mach-O binary and explicitly lists the combined components (IPA parsing, ObjC class dump, etc.). This distinguishes it from individual sibling tools like analyze_macho_objc or check_encryption, making its purpose very specific and unambiguous.
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 implies this tool is for comprehensive analysis when you want all static checks combined, while siblings are for specific sub-tasks. It does not explicitly state 'when not to use' or alternative scenarios, but the context of sibling tools provides implicit guidance. A score of 4 reflects clear context without explicit exclusions.
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:

[![re-ios MCP server](https://glama.ai/mcp/servers/gyh20062008-commits/re-ios/badges/card.svg)](https://glama.ai/mcp/servers/gyh20062008-commits/re-ios)

Score Badge

Copy to your README.md:

[![re-ios MCP server](https://glama.ai/mcp/servers/gyh20062008-commits/re-ios/badges/score.svg)](https://glama.ai/mcp/servers/gyh20062008-commits/re-ios)

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/gyh20062008-commits/re-ios'

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