Microsoft 365 Copilot RemoteMCPServer action registered, but no function rows or executions

Developer mode is the supported read-only diagnostic: use its separate Matched functions, Selected functions for execution, and Executed actions stages to locate the failure boundary; however, Microsoft does not document an empty pinned-function table as a specific rejection code or provide a public diagnostic that conclusively distinguishes package/tool rejection from an internal availability failure.

Interpret the developer-mode stages

For one new conversation, run:

-developer on

Then issue a prompt that explicitly names the action and requests one unambiguous operation. Inspect the resulting card in this order:

1. Action ID and version
   • Confirms only that the action registration/version is recognized.
   • It does not establish that the pinned functions entered the runtime app index.
2. Matched functions
   • These are functions returned by the runtime app-index lookup.
   • No matched functions normally means the prompt did not explicitly mention the action name. Microsoft documents that interpretation, but it does not explain the stronger case where the action is present and no configured function rows are displayed at all.^1^
3. Selected functions for execution
   • A matched function can still be omitted here if orchestration does not select it.
   • “No functions selected for execution” is documented as an intent/description mismatch; throttling is mentioned only when the functions previously worked.^1^
4. Executed actions
   • Rows here are created for actual invocations and include status, latency, endpoint, HTTP method, headers, and response.
   • Therefore, Executed Actions = 0 and no backend ingress establish that no tool call was dispatched for that prompt. They do not identify why the functions were unavailable.^1^

In this case, the useful discriminator is whether the three pinned names appear under Matched functions:

• Names appear but are not selected: investigate semantic selection and descriptions.
• Names are selected but execution has no request: capture the debug details and escalate as a pre-dispatch failure.
• No function rows appear although the correct action/version is registered: the public diagnostic has localized the failure before matching/selection, but it does not expose whether that resulted from package/tool validation, availability, or another service-side stage.

What the pinned-tool documentation establishes

Pinned tools must be present in all three relevant locations:

• top-level functions;
• mcp_tool_description, inline or file-based;
• the runtime’s run_for_functions.

For pinned tools, definitions are resolved from the packaged manifest at publish time rather than fetched through runtime tools/list discovery.^2^ Microsoft’s MCP troubleshooting page gives the same pinned-tool checks and says available tools appear in the debug card’s Actions section.^3^

Since those structural checks, inline/file variants, endpoint verification, and complete Base URL have already been tested, repeating them would not discriminate this case. Schema and package acceptance also do not prove component runtime success; Microsoft’s validation guidance explicitly says not to redefine a component failure as package success.^4^

No cited Microsoft documentation assigns a specific meaning such as “tool-definition rejected” to an entirely empty pinned-function table. Runtime validation withholding is documented for newly discovered or modified dynamic tools, not as an explanation for pinned tools.^2^

Escalation without tenant-wide access

Use the in-product feedback path from the affected conversation:

1. Select thumbs down on the agent response.
2. Include #extensibility.
3. State that the registered pinned RemoteMCPServer action/version is visible, but its configured-function rows are empty, no function is selected, and no request reaches the endpoint.
4. Include the privately retained agent version, conversation ID, request ID, timestamp, and sanitized diagnostic card details in the private report—not in the public Q&A post.

Microsoft documents this reporting route directly from developer mode.^1^

For community-level developer help, Microsoft 365 Copilot Development on Microsoft Q&A is the documented channel. For service-side investigation or SLA-backed support, the documented route is Microsoft 365 admin center → Help & Support → Support Assistant, or a service request when covered by Premier/Unified support.^5^ The documentation does not identify a separate public developer-support endpoint that can query internal indexing or validation state. In-product #extensibility feedback is therefore the documented route that does not require granting the developer tenant support roles or cross-tenant access.

References

1. Use developer mode in Microsoft 365 Copilot to test and debug agents
2. Dynamic tool discovery for MCP plugins in Microsoft 365 Copilot
3. Troubleshoot MCP apps in Microsoft 365 Copilot
4. Test and validate your plugin for Microsoft 365 Copilot
5. Support and feedback