Check Facebook auth and first sync
| Name | Required | Description | Default |
|---|---|---|---|
| connect_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | ||
| retryable | No | ||
| support_ref | No |
Changes observed during successful MCP inspections.
Output schema / $defsAdded value: +{
+ "s0": {
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "has_more": {
+ "type": "boolean"
+ },
+ "items": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "null",
+ "string"
+ ]
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "items",
+ "has_more"
+ ],
+ "type": "object"
+ },
+ "s3": {
+ "properties": {
+ "status": {
+ "enum": [
+ "requires_validation",
+ "awaiting_assets",
+ "blocked"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "summary"
+ ],
+ "type": "object"
+ }
+}Output schema / else / properties / asset_refreshAdded value: +{
+ "properties": {
+ "complete": {
+ "type": "boolean"
+ },
+ "created_at": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "finished_at": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "last_refreshed_at": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "launch_readiness": {
+ "$ref": "#/$defs/s3"
+ },
+ "refresh_scope": {
+ "enum": [
+ "tenant",
+ "fb_user"
+ ],
+ "type": "string"
+ },
+ "refresh_summary": {
+ "properties": {
+ "failed_connections": {
+ "items": {
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "failed_connections_count": {
+ "type": "integer"
+ },
+ "failed_connections_has_more": {
+ "type": "boolean"
+ },
+ "launch_readiness": {
+ "$ref": "#/$defs/s3"
+ },
+ "observed_at": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "routing_errors": {
+ "type": "integer"
+ },
+ "scope": {
+ "enum": [
+ "tenant",
+ "fb_user"
+ ],
+ "type": "string"
+ },
+ "updated_assets": {
+ "properties": {
+ "ad_accounts": {
+ "$ref": "#/$defs/s0"
+ },
+ "businesses": {
+ "$ref": "#/$defs/s0"
+ },
+ "pages": {
+ "$ref": "#/$defs/s0"
+ }
+ },
+ "required": [
+ "ad_accounts",
+ "pages",
+ "businesses"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "observed_at",
+ "scope",
+ "updated_assets",
+ "failed_connections",
+ "launch_readiness"
+ ],
+ "type": [
+ "null",
+ "object"
+ ]
+ },
+ "requested_scope": {
+ "enum": [
+ "tenant",
+ "fb_user"
+ ],
+ "type": "string"
+ },
+ "started_at": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "task_ref": {
+ "type": "string"
+ },
+ "task_status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "complete"
+ ],
+ "type": "object"
+}Output schema / else / properties / ready_scopeAdded value: +{
+ "enum": [
+ "onboarding_only"
+ ],
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's brief 'Check' is consistent. The description does not contradict annotations. However, it adds minimal behavioral context beyond the annotation: it specifies the scope ('auth and first sync') but does not explain what 'check' entails (e.g., whether it verifies token validity, fetches status, or returns partial results). With annotations covering the safety profile, the description provides a small additional detail, warranting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase ('Check Facebook auth and first sync') that is front-loaded with the verb and key nouns. It is efficient with no wasted words, though it could benefit from stating the purpose more explicitly, but given the simplicity, it earns a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 param, read-only annotations, and an output schema presumably), the description is short but sufficient to convey the basic action. However, it does not explain what 'first sync' means precisely, nor does it provide enough context for an agent to know what conditions warrant calling this tool versus other setup checks. The output schema exists, so return values are not the description's responsibility, but the usage context is incomplete, leaving the score at 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description is the only source of parameter meaning. However, there is only one parameter, connect_id, and the description does not explain its format or purpose (e.g., whether it's the Facebook connection ID or a setup ID). The description's phrase 'Check Facebook auth' hints that connect_id identifies the connection, but it does not elaborate on how it is used or what values are expected. Since there are no other parameters, the description does not compensate for the lack of schema documentation, so a 3 is appropriate (the schema's name provides some meaning, but the description adds little).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check'), resource ('Facebook auth and first sync'), and context ('first sync'). It is clear enough that the tool checks the state of Facebook authentication and initial synchronization, but it does not explicitly differentiate it from similar siblings like setup_begin_facebook_connect or setup_check_channel_connect, though the 'first sync' detail hints at a setup validation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a setup-related check, likely to be used during the Facebook connect flow, but it does not state when to use it versus alternatives (e.g., setup_begin_facebook_connect, setup_get_status, or setup_check_channel_connect). No explicit context or exclusions are provided, leaving the agent to infer the appropriate moment from the name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.