facebook-lyr
Server Quality Checklist
Latest release: v0.3.1
- Disambiguation4/5
Most tools target distinct resources and actions (e.g., get_page_posts vs. get_user_posts vs. get_group_posts, create_post vs. create_photo_post). A few overlaps exist, such as get_me, get_account_status, and get_active_account_info, but their descriptions clarify the intent.
Naming Consistency4/5The majority follow a verb_noun pattern (get_*, create_*, delete_*, search_*, list_*, switch_*, set_*, add_*, remove_*). Minor deviations like get_me, comment_on_post, and send_typing_indicator are acceptable but prevent a perfect score.
Tool Count2/5At 41 tools, the count exceeds the 'too many' threshold of 25+. While the server covers a broad Facebook surface, many tools could be consolidated (e.g., generic post retrieval per resource type) without losing capability.
Completeness4/5The tool surface covers account management, posts, comments, pages, groups, search, and Messenger with create/read/delete operations. Minor gaps exist, such as no update_post, no delete_comment, and no group creation, but core workflows are well supported.
Average 4.1/5 across 41 of 41 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds no additional behavioral context such as pagination, ordering, or filtering behavior. It merely restates the purpose, providing no value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—five words—and front-loads the core action. It is not bloated, but it sacrifices informative detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations plus output schema cover safety and return values, so the minimal description is acceptable for basic use. However, it lacks any usage context or edge-case behavior, making it barely adequate for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: both post_id and limit have detailed descriptions. The tool description adds no parameter information beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('comments') with a scope ('on a post'), clearly distinguishing it from sibling tools like comment_on_post or get_post_details. It is unambiguous, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only states the action, without conditions, exclusions, or references to related tools. The schema's post_id description hints at a source for the ID, but that's parameter-level information, not usage guidance.
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 of behavioral disclosure, but it only states what the tool does. It does not mention side effects, whether the indicator is ephemeral, or any interaction with the other participant. This is minimal and lacks transparency 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no redundant phrases. It front-loads the action and specifies the target, and the parenthetical adds essential clarification without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description provides the core function, but it lacks usage context and behavioral details that would make it complete. The output schema exists, so return values are covered, but the missing guidelines and transparency make it minimally sufficient rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (thread_id and typing). The description's parenthetical 'typing_on / typing_off' restates the schema's boolean description but adds no new semantic detail. Therefore, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a typing indicator to a conversation, with the parenthetical 'typing_on / typing_off' clarifying the two possible states. This uses a specific verb and resource, distinguishing it from sibling tools like send_message or mark_conversation_seen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context (e.g., 'send before composing a message'). The sibling context exists but the description itself offers no explicit usage instructions.
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 readOnlyHint annotation already declares a non-mutating operation. The description adds that it checks 'posting limits and history' but does not disclose further behavioral details such as error handling or rate limits. Consistent with the annotation, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb 'Check' and contains no filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple 1-parameter schema, an output schema, and a readOnly annotation, the description is mostly sufficient. However, it lacks context about what 'posting limits' entails and when to use this tool over similar ones, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the optional parameter with an explicit description ('Account id (defaults to the active account)'), making schema coverage 100%. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Check' and specifies the resource as 'a stored identity's posting limits and history', which is specific and distinguishable from siblings like get_account_status. However, 'stored identity' is somewhat vague, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or how it differs from alternatives. It is a single factual statement with no mention of use cases 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'by name' scoping constraint, which is useful, but it doesn't disclose other behaviors like pagination, result ordering, or rate limits. This matches the calibration example for get_calls, which also received a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and appropriate for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward search tool with an output schema and readOnly/openWorld annotations, the description covers the essential purpose. It lacks usage guidance, but the tool's simplicity and the presence of an output schema reduce the burden. The 'by name' qualifier adds a key constraint, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'query' and 'limit' parameters documented in the schema. The description adds the 'by name' qualifier but does not provide additional meaning beyond the schema. Baseline 3 is appropriate when the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Facebook groups by name, using a specific verb and resource. It distinguishes itself from people/page/post search siblings by specifying 'by name', though it doesn't explicitly differentiate from similar group-related tools like get_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_group, search_pages, or other search tools. The description simply states what it does without 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds no extra behavioral context (e.g., return format, required auth, rate limits), but it doesn't contradict the annotations. With annotations covering the primary trait, a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, front-loaded with the verb and resource. Every word earns its place; no filler or redundancy. This is appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter with a clear schema description), the presence of an output schema, and annotations covering read-only behavior, the minimal description is sufficient. It doesn't explain return values, but the output schema presumably does. Sibling context further clarifies its role, making it complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed description for group_id ('Numeric group id (from search_groups)'), so the description need not add more. The tool description itself adds no parameter semantics, but the schema does the heavy lifting, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Facebook group details' uses a clear verb ('Get') and resource ('Facebook group'), and 'details' implies general group information, distinguishing it from siblings like get_group_posts and get_group_members which target specific aspects. However, it doesn't explicitly differentiate from those siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the parameter description 'Numeric group id (from search_groups)' implies usage after searching for a group. This is implicit guidance but lacks explicit exclusions or alternative recommendations, so it's a minimal viable score.
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 annotations already declare readOnlyHint=true, so the description need not restate that. The description adds the concept of 'recent' posts, implying time-based filtering, but does not disclose additional behaviors like pagination, rate limits, or ordering specifics beyond the schema. No contradiction with annotations; it provides some value but not rich 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word contributes to meaning, with no redundant or filler content. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description is minimal but adequate, especially with readOnlyHint=true and a complete input schema. The output schema likely covers return structure, so the description need not elaborate. However, it omits any mention of ordering or default limits, though these are implicit in the schema. It is complete enough for a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (group_id and max_posts) with descriptions, achieving 100% schema coverage. The tool description does not add any extra semantic meaning beyond what the schema already provides, so it relies on the schema as the baseline. No additional clarification is offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent posts from a group feed, using a specific verb ('Get') and resource ('group feed'). It naturally distinguishes from sibling tools like get_page_posts and get_user_posts by the group context. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_page_posts or get_user_posts. The description does not mention any exclusions, prerequisites, or conditions that would help an agent choose it over other post-retrieval tools. This is a clear gap given the many sibling tools.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds 'recent' and 'timeline' context, which is slightly more than the schema. However, it does not disclose any additional behavioral traits such as ordering, pagination, or potential failure modes for private accounts. With annotations present, this is acceptable but not highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, with no redundant or unnecessary information. It is front-loaded with the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters), has a complete input schema, and an output schema exists. Annotations cover the read-only/open-world behavior. The description is minimal but sufficient for this simple list operation, though it could clarify the difference between 'user' and 'Page' timelines, especially given the sibling get_page_posts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both username and max_posts are fully described in the input schema. The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('recent posts') and scope ('from a user's or Page's timeline'). This distinguishes it from sibling tools like get_group_posts, though it overlaps slightly with get_page_posts. The mention of 'recent' adds a time qualifier that matches the max_posts parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like get_page_posts or search_posts. It does not mention exclusions, prerequisites, or alternative tool names. The only implied usage is that it retrieves recent timeline posts, which is not enough for effective tool selection among many similar read tools.
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?
Annotations already declare destructiveHint=true, so the agent knows this is destructive. The description adds clarity that the destruction is limited to the cookie set, which is useful. However, it does not disclose side effects like whether the account is also removed from the account list or if this affects the active session, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Remove' and a clear object. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with an output schema present, the description is mostly complete. It explains the core action and scope. However, it could mention whether the removal is permanent or if the account must exist, but these are minor omissions given the simplicity and the available schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, account_id, with a description 'The account id to remove'. The tool description adds no additional parameter-level detail, so it relies entirely on the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: remove, and the target: a stored Facebook identity's cookie set. This is specific and distinguishes it from siblings like update_account_cookies or close_session. Although the title says 'Remove Facebook Account', the description scopes it precisely to the cookie set, avoiding ambiguity about deleting the actual account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, such as the account needing to be stored, or scenarios like removing an inactive account vs switching away. The agent must infer usage from the tool name and sibling context, which is not explicit.
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 already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds no additional behavioral context beyond that, such as ordering, pagination, or marking messages as read, so it fails to disclose any traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read operation with an output schema and annotations. However, the description is minimal and doesn't mention behaviors like message ordering, media inclusion, or pagination, leaving some gaps that the output schema may or may not cover. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes thread_id with type, length, and a helpful description 'Conversation id (from get_conversations)'. Since schema coverage is 100%, the baseline is 3; the tool description itself adds no parameter information, but the schema is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with resource 'messages from a Messenger conversation', clearly distinguishing it from siblings like send_message and delete_message, and from get_conversations which lists conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for reading messages, and the thread_id parameter says 'Conversation id (from get_conversations)', implying a workflow of first getting conversations. However, it doesn't explicitly state when to use this over alternatives like get_conversations or mark_conversation_seen.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds the 'authenticated account' scoping but nothing else. It does not disclose behaviors like pagination, ordering, or auth requirements beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, front-loaded with the verb. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, a fully documented parameter, and clear annotations, the description is adequate for a simple read-only list tool. It could mention ordering or filtering, but that is not necessary for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'limit' parameter is fully described in the input schema (100% coverage), including min/max/default. The tool description adds nothing beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action 'List' and resource 'Messenger conversations' with scope 'for the authenticated account', clearly distinguishing it from sibling tools like get_conversation_messages. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as get_conversation_messages or search_people. It implies its use through the resource name but lacks clear 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is established. The description adds the scope of 'timeline' and 'recent posts,' which provides some behavioral context. However, it does not disclose potential limitations (e.g., pagination, authorization requirements) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without any unnecessary words. It is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, output schema present) and strong annotations, the description is mostly complete. It covers the essential purpose but leaves some context implicit, such as the exact format of 'recent posts' or behavior when the page is invalid, though these are partially inferred from the output schema and tags.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the input schema (username example, max_posts bounds/default). The description itself does not add additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get recent posts from a Facebook Page's timeline.' The verb 'get' identifies it as a retrieval operation, and the resource is specifically 'recent posts from a Facebook Page's timeline,' which distinguishes it from siblings like get_group_posts or get_user_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Facebook Page's timeline') and distinguishes it from other post-related tools by the word 'Page,' but it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds valuable context by specifying 'all active API clients' (not just the current one) and 'clean up resources.' It does not detail reversibility or token invalidation, but the added scope is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of eight words that communicates the action and scope clearly. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core action and scope, and an output schema exists so return values need not be explained. However, it lacks usage guidance (e.g., when to call it) and does not mention side effects like auth token invalidation, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the baseline is 4. The description's mention of 'all active API clients' provides extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Close' with resource 'all active API clients' and adds 'clean up resources,' clearly distinguishing this from sibling tools focused on accounts or posts. It is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool, such as before logout or after a task, nor does it mention alternatives. It provides no contextual guidance about typical workflows or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is light. It adds the key contextual detail that only 'public posts' are searched, which is valuable scoping information not present in the annotations. No contradictions exist, and the description aligns with the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, precise sentence with no filler. It front-loads the core function (search) and the resource (public posts), and the keyword mechanism is immediately clear. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, full schema coverage, useful annotations (read-only, open-world), and presence of an output schema, the description is complete. It states the core behavior and scope ('public posts'), and no additional behavioral details are necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully defines 'query' and 'limit' with clear descriptions. The tool description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search public posts by keyword.' It identifies a specific verb (search), resource (public posts), and mechanism (keyword). While it doesn't explicitly differentiate from sibling search tools like search_groups or search_people, the resource 'public posts' provides sufficient distinction for most cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('search public posts') but provides no explicit guidance on when to use this tool versus alternatives. There are no exclusions or mention of sibling tools for specific scenarios (e.g., searching a user's posts with get_user_posts). The context is minimal and relies on the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond annotations: 'Each image is validated and normalized before the upload attempt' and 'Best-effort: modern Facebook may reject cookie-based carousels; failures surface as clear, honest errors.' This exceeds the minimal annotation coverage (idempotentHint, destructiveHint) and provides useful failure-mode context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: two short sentences for the core purpose plus two sentences for behavioral context. Every sentence earns its place, and the most important information (upload and publish) is front-loaded. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a multi-photo publish operation, the description covers the essential action, validation, and potential failure mode. The schema documents parameters and output schema exists. The only minor gap is the lack of explicit mention about the irreversibility of publishing (covered by destructiveHint), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add significant meaning beyond what the schema already provides. The mention of 'multiple photos' loosely aligns with the `sources` parameter, but it does not clarify formats, limits, or the confirm flag beyond schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Upload multiple photos and publish them as one carousel post.' This specific verb+resource phrasing distinguishes it from sibling tools like create_photo_post (single photo) and create_video_post (video).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'multiple photos' – it should be used when creating a post with multiple images. However, it does not explicitly contrast with alternatives or state when NOT to use it (e.g., for single photo, use create_photo_post). No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals mutation, but the description adds valuable context: image validation/normalization, best-effort upload that may be rejected by Facebook, and clear error surfacing. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, followed by relevant operational details. It is concise and every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete schema, output schema, and annotations, the description adequately covers the tool's purpose, image processing, and failure modes. It does not explain return values, but the output schema covers that. Minor gaps like the confirm parameter behavior are already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the baseline is 3. The description adds some context about the source being validated and normalized, but does not add new parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Upload a photo and publish it') and distinguishes this tool from siblings like create_video_post and create_carousel_post. It also specifies the identity context, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for photo posts but does not explicitly contrast with alternatives like create_video_post or create_carousel_post. It provides a useful caveat about cookie-based uploads but no explicit when-to-use or when-not-to-use guidance.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, read-only operation. The description adds no additional behavioral context beyond restating the action (get details). It does not mention error behavior, authentication needs, or rate limits, but the bar is lower due to the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and directly states the tool's function and input. It earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema, the read-only annotations, and the existence of an output schema, the description is sufficient to guide invocation. It doesn't explain the return value details, but that is covered by the output schema per the rules. The only minor gap is that the description doesn't explicitly mention the platform (e.g., Facebook), but the schema example fills this. Overall, adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (post_url) with a clear description and example, so schema coverage is 100%. The tool description simply says 'by its URL', which adds no new meaning beyond what is already provided in the schema. Thus the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get details), the resource (a single post), and the key input (its URL). This distinguishes it from sibling tools like get_user_posts or get_post_comments, which deal with lists or comments. The purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: when you have a post URL and need its details. It does not explicitly mention when not to use it or name alternatives, but the context is clear from the phrasing 'by its URL'. No exclusion or alternative guidance is provided, but the implied usage is straightforward.
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 empty annotations, the description discloses the primary behavioral effect (clearing the unread badge) but does not mention other consequences (e.g., notifying the other participant via a 'seen' receipt), permission requirements, or reversibility. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content. The parenthetical efficiently clarifies the real-world effect of the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter state-change tool, the description and schema together provide sufficient context. The output schema exists, so the description need not explain return values; the only missing element is explicit failure/error behavior, which is minor for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter thread_id is described as 'Conversation id'. The tool description adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') and a specific resource ('Messenger conversation'), and clarifies the outcome ('clears the unread badge'). This clearly differentiates it from sibling tools like get_conversations or send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended context obvious: use when you want to clear an unread badge for a conversation. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent would not confuse it with sending messages or fetching conversations.
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 adds context that this updates stored cookies for an existing identity and is useful for session refresh. Annotations (destructiveHint, openWorldHint) already flag a potentially destructive write, but the description does not elaborate on side effects like overwriting old cookies. Some added value, but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Update cookies...') and a practical use case. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter update tool with an output schema present, the description covers the purpose and common scenario. It does not address error handling or invalid cookie scenarios, but given low complexity and schema/annotation support, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions (account_id and cookies as a dict with c_user + xs), giving 100% coverage. The description adds no further parameter-specific details beyond the general use case, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: 'Update cookies for an existing stored Facebook identity.' This clearly distinguishes it from sibling tools like add_account or remove_account by focusing on the cookie update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'refreshing an expired session without re-adding the account.' This implies an alternative action (re-adding) and suggests when to use, but does not explicitly state exclusions or when not to use.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds 'recent' and the types of notifications included, but does not disclose pagination behavior, rate limits, or return format details. With annotations covering safety, a 3 is appropriate—it adds some context but not rich behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose, then types, then use case. Every sentence earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and an output schema, the description is sufficient. It covers what the tool returns conceptually, when to use it, and the parameter is fully documented in the schema. No important aspects are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter, 'limit', is fully described with min, max, default). The tool description does not add any additional meaning about this parameter, so the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'List the authenticated identity's recent Facebook notifications.' It also enumerates notification types (message alerts, tags, follows, page activity) which clearly distinguishes it from sibling tools that operate on groups, posts, messages, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for an agent to know what needs attention before deciding to act' provides a clear context for when to use this tool. However, it does not explicitly name alternatives or specify when-not-to-use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: true, so the agent knows this is a safe read operation. The description adds no extra behavioral context beyond the purpose, but it doesn't contradict annotations. Given the read-only nature, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero filler. It front-loads the purpose and immediately provides a practical usage context, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, full schema coverage, and an output schema. The description covers purpose and usage, while annotations cover safety and output schema covers return values, so it is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (query as name, limit with range and default). The description adds no additional meaning beyond what the schema already states, so it meets the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for people by name', which is a specific verb+resource action. It distinguishes this tool from sibling search tools like search_groups or search_pages by focusing on people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful to find a person before messaging them (pair with get_conversations / send_message)'. This tells the agent when to use the tool, but it doesn't explicitly mention when not to use it or name alternative search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. The description adds valuable context: video validation happens before upload, the operation is best-effort due to Facebook decommissioning cookie-based uploads, and failures are surfaced as clear errors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action, and each sentence carries essential information without redundancy. The caveat about Facebook decommissioning is concise and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with annotations and schema, covers the mutation nature, validation, failure behavior, and identity scope. It could be more explicit about when to use it vs sibling post-creation tools, but overall it is sufficiently complete for a 4-parameter tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all four parameters, so the description does not need to explain each param. It adds context about validation and identity selection, but not enough to raise above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Upload a video and publish it') with a resource ('video') and identity scope. It clearly distinguishes from sibling tools like create_photo_post or create_carousel_post by focusing on video uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this tool is for video posts via the verb 'Upload a video and publish' and the identity mention. However, it does not explicitly state when not to use it or reference alternatives (e.g., use create_photo_post for photos).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context: it 'fetches the public (or logged-in) profile page and parses ... from embedded page data,' indicating a scraping mechanism and possible dependence on login status. This goes beyond the annotations and helps the agent understand what actually happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary purpose in the first sentence and details in the second. No filler or redundant information; every word adds value. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, an output schema, and read-only annotations, the description covers the essential purpose and data extracted. It does not describe return values, but the output schema likely does. The only minor gap is lack of mention of rate limits or login requirements, but the 'logged-in' hint and annotations provide enough for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the username parameter already explained as 'Page or profile username (e.g. 'cocacola')'. The description adds only the phrase 'by username,' which adds no new semantics. The schema carries the burden, so a baseline score of 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Facebook Page/profile details by username' with a specific verb and resource, then lists the exact data extracted (name, id, bio, follower counts). This distinguishes it from siblings like get_me (own profile), search_pages (search), or get_page_posts (posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a username and want profile details, providing clear context. However, it does not explicitly mention when not to use it or name alternatives (e.g., use get_me for the logged-in account, search_pages for searching). Still, the 'by username' phrasing gives enough guidance for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that only public Pages are searched and that the search is name-based, offering useful scope beyond the annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with a clear output schema and supportive annotations, the description is sufficient. It covers the scope (public pages by name) and does not leave critical gaps, though it does not address potential behaviors like case sensitivity or exact matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already documented. The description's 'by name' clarifies the query parameter's purpose but does not significantly add value beyond the schema's existing 'Search term' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and clearly identifies the resource as 'public Facebook Pages' with the qualifying phrase 'by name'. This distinguishes it from sibling search tools like search_groups, search_posts, and search_people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for locating public Facebook Pages by name, providing clear context for when to use it. However, it does not explicitly mention alternatives or exclusions, though the sibling list makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it explains that cookie scraping acts as the imported account, and that this tool merely records a Page without switching identity. While the destructiveHint annotation is not contradicted or elaborated on, the description provides useful non-obvious details about its effect on session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in the first sentence. The subsequent note is useful but slightly verbose, containing tangential context about cookie scraping that could be tightened without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a niche state-setting tool with an output schema and destructiveHint annotation, the description is thorough. It explains the purpose, its limitations (no identity switching), and the context for Page-mode sessions, making it complete enough for an agent to use correctly without needing to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters page_id and page_name are already well-documented. The description does not add any parameter-specific meaning, staying at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'persists the active Facebook Page for display/context purposes', using a specific verb and resource. It distinguishes itself from account-switching tools by explicitly noting it does not switch the acting identity, and from other Page-related tools by focusing on bookkeeping and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool (display/context, agent bookkeeping, Page-mode sessions) and an important exclusion ('does not switch the acting identity'). However, it does not explicitly name alternative tools like switch_active_account, leaving the agent to infer the alternative from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral nuance beyond the annotations: it describes the operation as 'best-effort' with the legacy endpoint, notes that confirmation may not be synchronous, and instructs verifying in the Saved collection. This transparency about asynchronous behavior and follow-up action is highly valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose, the second explains a key behavioral caveat. There is no fluff or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for this simple tool: it covers the main action and a critical behavioral caveat. The confirm parameter's requirement is already in the schema, and an output schema exists, so return values need not be described. The lack of an explicit mention of confirm=true is not a gap since schema covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (post_id, confirm, account_id) already described in the schema. The description's phrase 'active (or specified) identity' restates the account_id default but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove a post from the active (or specified) identity's Saved' with a specific verb (remove), resource (post from Saved), and scope (identity). It clearly distinguishes this from sibling tools like save_post (adds to Saved) and delete_post (removes the post entirely).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose (use when you need to unsave a post), but there is no explicit guidance about when to use versus alternatives or any exclusions. The description does not mention that save_post is the complement, nor does it explain that delete_post would permanently delete the post rather than just removing it from Saved.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds behavioral context by outlining the return dict fields (valid, cookie_source, me, active_page), but does not delve into side effects, permissions, or edge cases. It goes slightly beyond the annotation but not substantially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear 'Returns:' section to list output fields. No unnecessary words or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, read-only, output schema exists), the description covers the essential meaning and return values. It is complete for an agent to understand when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% coverage (empty schema). The description correctly adds no param details. Per the baseline for 0 params, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('cookie-session status and active Page'). The return list further clarifies what it provides. This distinguishes it from sibling tools like get_me or get_active_account_info, which focus on different aspects of account state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using this tool (to inspect session validity and active page) but does not explicitly name alternatives or specify when not to use it. Since the context is clear and no exclusions are stated, this fits a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds useful context that when no active account is set, a message is returned, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence plus a return note. It front-loads the purpose and avoids any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter with an output schema, the description provides sufficient information, including the edge case of no active account. The annotations and schema handle the remaining details, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers this completely (100% coverage). The description appropriately omits parameter details, so a baseline of 4 applies for such parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get information about the currently active Facebook identity' using a specific verb and resource. It distinguishes from siblings by the 'active' qualifier and explicitly notes the return behavior of metadata or a message when none is set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving active account info but does not explicitly mention alternatives or when to prefer this over similar tools like get_me or list_accounts. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint and openWorldHint annotations by specifying that only embedded event rows (id, name, start_date_time, url) are returned, and that client-side details are not accessible. This discloses the tool's scope and limitation, which is helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and includes only relevant details about return format and a key limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema, readOnlyHint/openWorldHint annotations, and the presence of an output schema, the description is complete enough. It explains what data is returned and its limitation, covering the essential context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for the single limit parameter (coverage 100%), and the tool description adds no additional parameter semantics. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists upcoming events relevant to the authenticated identity, using a specific verb and resource. It further specifies the data source ('events hub') and the returned fields, distinguishing it from sibling tools that operate on posts, groups, or notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists upcoming events for the authenticated identity. It also includes an important caveat that client-side event details are not available via cookie scraping, which informs when not to rely on this tool. However, it does not explicitly name alternative tools for obtaining such details, so it falls short of a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only non-destructive and open-world hints. The description adds that the tool loads the selected identity's cookie set and that subsequent calls act as that identity, disclosing persistence and scope. This goes beyond the annotations but does not cover potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences. The first states the core purpose, and the second explains the mechanism and effect. Every word contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter, an output schema, and annotations. The description adequately covers the main behavior and its implications for subsequent calls, which is the most important contextual information. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter account_id with a description ('The stored account id to activate'), so the description adds no extra meaning. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Switch which stored identity all tools act as', specifying a clear action and resource. It explains the effect on subsequent tool calls, distinguishing it from siblings like list_accounts or set_active_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool—to change the active stored identity—and explains that subsequent calls use that identity's cookie set. It does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it explains that adding an account can change the active identity ('when set_as_active is True (default)') and specifies the required cookie fields. This complements the destructiveHint annotation rather than contradicting it. It does not cover every edge case (e.g., what happens if the account already exists), but it discloses the key behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every sentence carries crucial information. It avoids redundancy and fluff, making it highly efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, a nested object, and an output schema, the description covers the core requirements (cookies, active identity change) without needing to explain return values. It is complete enough for an agent to understand the main use case, though it could mention error conditions or validation behavior for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 6 parameters, but the description adds essential semantics for the cookies parameter by specifying it 'must contain at least c_user and xs' as a logged-in session. It also clarifies the effect of set_as_active on subsequent tool actions. This adds value over the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Store a new Facebook identity's cookie set for agent use.' It specifies the resource (Facebook identity cookie set) and scope (new identity), distinguishing it from sibling tools like update_account_cookies or import_account_from_browser. The title 'Add Facebook Account' aligns with this clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives solid context for when to use the tool: when you have a logged-in facebook.com session cookie set with at least c_user and xs. It also explains the behavioral consequence ('After adding, all tools act as this identity') but does not explicitly mention alternatives or when not to use it, such as comparing with import_account_from_browser. Thus, clear context but lacking explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses concrete behaviors: checks posting limits, records the attempt, uses a confirm flow (delete.php), and fails honestly for already-deleted or decommissioned deletions. This is rich, non-redundant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary action, and every sentence adds meaningful information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and destructiveHint annotation, the description covers purpose, scope, process, side effects, and failure modes. It does not explicitly state that confirm=true is required, but the schema covers that. Overall, it is sufficiently complete for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear per-parameter descriptions. The description's mention of 'confirm flow' hints at the confirm parameter but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource: 'Delete one of the active (or specified) identity's own posts.' This clearly distinguishes from sibling tools like save_post, unsave_post, and delete_message, and specifies the scope (own posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use to delete posts owned by the active or specified identity. It does not explicitly name alternatives or when-not conditions, but the scope restriction is evident and provides a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking it as open-world and destructive, the description adds meaningful context: it uses the same machinery as --login and requires the browser to be logged in. This goes beyond the annotations by explaining the import mechanism and a key prerequisite. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and includes only necessary details. Every sentence earns its place—no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, annotations, output schema), the description is reasonably complete. It covers the action, mechanism, prerequisite, and an example. It could mention what happens to existing cookies or whether a new account is created, but the output schema and annotations cover the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The description adds extra value by providing an example ('a Page whose session is open in your browser profile') that clarifies the identity_type and browser parameters. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it imports a Facebook identity's cookies directly from a browser, using a specific verb and resource. It also distinguishes itself from sibling tools like add_account or update_account_cookies by emphasizing the 'from a browser' source and the native cookie import machinery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use: when the browser is logged into the identity, and it mentions the native machinery equivalent to --login. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: the legacy save endpoint is best-effort and cannot always confirm synchronously, so the result must be verified in the Saved collection. This goes well beyond the idempotentHint annotation and helps set expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed by a concise caveat about synchronous confirmation. Every word adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with an output schema, idempotentHint annotation, and full schema parameter coverage. It covers the essential context of identity targeting and the best-effort backend behavior, though it stops short of mentioning the unsave_post sibling or the confirm parameter requirement explicitly (both are inferable).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (post_id, confirm, account_id) are already well-documented in the schema. The description adds no additional parameter-level information, but it does reference the active/specified identity concept that maps naturally to account_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Save/bookmark a post to the active (or specified) identity's Saved.' This clearly identifies the tool's action and target, and it is implicitly distinguished from the sibling unsave_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by indicating the action applies to the active identity or a specified identity via account_id. It does not explicitly mention alternatives like unsave_post or when not to use, but the purpose is unambiguous and the identity-scoping guidance is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses precise operational steps: validates text, checks posting limits, records the attempt, and comments via the web composer. It also honestly notes a specific failure mode (cookie-based commenting decommissioned). This is substantial transparency that the annotation alone does not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences totaling about 40 words. The first sentence front-loads the purpose, the second packs operational details without fluff. Every phrase earns its place, and it remains highly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, a destructive hint, and an output schema present, the description provides the essential behavioral context: what it does, how it does it, and a known failure condition. It does not need to explain return values because an output schema exists. The tool is well-covered for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with all four parameters documented (post_id, text, confirm, account_id). The description does not add deeper semantic meaning beyond the schema, apart from possibly reinforcing the 'active vs specified identity' concept, which the schema already captures. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb-resource pair: 'Comment on a post.' It also specifies the identity context (active or specified Facebook identity), which distinguishes it from siblings like create_post, delete_post, or send_message. The title and description align perfectly without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence implies the primary use case ('Comment on a post as the active identity'), giving clear context for when to invoke the tool. However, it does not explicitly mention alternatives or when-not-to-use, such as comparing with send_message or create_post. The behavior notes about validation and failure add situational awareness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (idempotentHint: false, destructiveHint: true) by disclosing that it validates text, checks posting limits, publishes via the web composer, and returns a clear error if cookie-based writing is decommissioned. This provides valuable behavioral context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, starts with the core purpose, then explains the process and failure handling. Every sentence earns its place with no repetition of schema information, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three fully documented parameters, an output schema present, and annotations for idempotency/destructiveness, the description adds sufficient context: it explains the publishing mechanism, validation, and error behavior. No critical information is missing for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters (coverage 100%) and already describes 'status', 'confirm', and 'account_id'. The description adds context for account_id (active vs specified identity) and mentions validation of text, but does not add syntax or format details beyond the schema, so it stays at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Publish' and the resource 'a text post', distinguishing it from sibling tools like create_photo_post and create_video_post. It also specifies the identity context ('active or specified Facebook identity'), 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for text posts only, which differentiates it from photo/video/carousel creation siblings. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint annotation by describing validation of ids, posting limit checks, attempt recording, legacy endpoint usage, and honest failure when decommissioned. This adds rich behavioral context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and then behavioral details. Every word earns its place with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature, annotations, and output schema, the description sufficiently covers side effects, failure modes, validation, and identity handling. The existence of an output schema means return values need not be explained in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about active/specified identity and validation, but does not substantially enhance parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete (unsend) a Messenger message' with a specific verb and resource. It distinguishes from sibling tools like delete_post by specifying 'Messenger message' and using the term 'unsend'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that the tool deletes as the active or specified identity and mentions the legacy Mercury endpoint. While it does not explicitly list alternatives or when-not-to-use, the 'unsend' terminology and resource scoping make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses significant behavioral traits: it is served from a legacy endpoint, may return errors for private groups or migrated surfaces, and the result explains limitations 'honestly'. This adds valuable context about failure modes and data origin that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that front-load the core purpose and then add relevant caveats. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two well-documented parameters and an output schema present, the description covers the essential purpose and behavioral limitations. The combination of annotations, schema, and description leaves little room for confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (group_id and limit) with descriptions and constraints. The tool description adds no additional parameter-specific explanation, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List members of a Facebook group' uses a specific verb ('list') and resource ('members of a Facebook group'), clearly distinguishing it from sibling tools like get_group, get_group_posts, or search_groups. It precisely conveys the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting it is 'best-effort' and may fail for private groups or migrated surfaces, which helps set expectations. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it reveals the tool relies on the imported browser-cookie session (c_user / xs) and implies it can validate session validity. With readOnlyHint=true, the read-only nature is already known, but the session dependency and its purpose are valuable additions. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences that cover purpose, usage context, and return value. It is front-loaded with the primary action, and every sentence earns its place. No unnecessary fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema present), the description is complete. It explains what the tool does, when to use it, and what it returns. The output schema exists, so return value details are redundant but still summarized. The description covers all necessary aspects for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously). Per the guidelines, a baseline of 4 is appropriate since no parameter documentation is needed. The description still adds useful context by explaining the underlying data source (cookies), which indirectly clarifies why no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the identity of the authenticated Facebook user' with a specific verb and resource. It distinguishes itself from sibling tools like get_account_status (which likely checks account status) and get_active_account_info (which might return active account details) by focusing on identity fields (id, name, username). The purpose is unambiguous and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Useful to confirm whose session is configured and whether it is still valid.' This tells the agent when to use the tool. It does not explicitly mention alternative tools or exclusions, but the context is sufficient for a focused identity tool. A slight improvement would be naming alternatives like get_account_status, but it's not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint), the description explains the cookie-based identity model and that the active identity affects all tools. This adds useful behavioral context without contradicting the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, leading with the core purpose, then a clarifying note about active identity, and finally the return format. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with an output schema, the description fully covers the needed context. It explains the identity model, active account relevance, and return fields, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description doesn't need to add parameter info; it focuses on the return structure, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all stored Facebook identities (cookie sets)' with a specific verb and resource. It distinguishes from sibling tools by emphasizing all stored identities and the concept of an active account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context on when to use the tool (to see all accounts) and directs users to switch_active_account for changing the active one. However, it doesn't explicitly mention alternatives like list_switchable_accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds valuable context on the underlying data source (Facebook's account switcher), what identities are included, and the return structure, going beyond the annotation defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences plus a return structure line. It leads with the core purpose, then the source and scope, then the returned shape. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-parameter list tool with an output schema, the description fully covers purpose, scope, source, and return value. It includes a note that it's the discovery source, which completes the behavioral context. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% vacuously. Per the rubric, 0 params earns a baseline of 4; the description also notes the return format, which is useful given no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Discover' and clearly identifies the resource: every identity the logged-in session can switch to. It distinguishes itself from siblings by naming the source, the account switcher, and the contents: Pages, linked profiles, and the user profile itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states its role: 'This is the discovery source an agent uses to learn which identities exist for this session.' This implicitly tells the user when to use it, but it doesn't mention when not to use it or name alternatives like get_me or list_accounts, which slightly weakens the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses significant behavior: validation, posting limits checks, attempt recording, and use of the legacy Mercury endpoint. It also mentions 'fails honestly' for decommissioned accounts, adding valuable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every clause adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity, the description covers key behavioral aspects (validation, limits, recording, endpoint, failure mode) and is complemented by an output schema, making it sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds minimal extra parameter meaning; 'active (or specified) identity' aligns with account_id but is redundant with the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('Messenger text message'), and clarifies identity handling ('active or specified identity'), which distinguishes it from sibling tools like create_post or comment_on_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's purpose for sending Messenger text messages, providing clear context. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ishan-parihar/facebook-lyr'
If you have feedback or need assistance with the MCP directory API, please join our Discord server