Register some utility Abilities

[dkotter]

What?

Adds in two new, what I'm calling "Utility Abilities" (open to naming suggestions). These are more simple Abilities as compared to our current Title Generation Ability. These take in a post ID and will return some information about that post, like title, content, author or terms. We then use these Abilities when building our post context.

Why?

While this does make our code slightly more complex and isn't the approach I'd generally take, adding these in does accomplish a few things:

1. Showcases a different, more simple approach to registering Abilities (compared to passing in a full class object)
2. Showcases how you can call Abilities via PHP
3. Showcases how you can combine multiple Abilities together and even call an Ability from another Ability

I originally had individual Abilities for each piece of context (like post content, post title, post author, etc) but after some feedback, trimmed it down to two Abilities, one to get all post details (which you can optionally filter to just the fields you want) and one to get all post terms (which you can also filter to just the taxonomies you want).

How?

• Adds a new Abilities class, Utilities, that registers two new abilities: get-post-details and get-post-tems. These Abilities aren't currently registered with the REST API
• Modifies our existing get_post_context helper function to instead use these new Abilities to build up that context

Testing Instructions

There isn't any UI yet to trigger things so you'd have to make a direct request to the Title Generation Abilities endpoint to see these in action

curl --location 'https://example.com/wp-json/wp-abilities/v1/abilities/ai/title-generation/run' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic ****' \
--data '{
    "input": {
        "post_id": 1,
        "candidates": 1
    }
}'

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dkotter <[email protected]>
Co-authored-by: JasonTheAdams <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

❌ Patch coverage is 0.40984% with 243 lines in your changes missing coverage. Please review.
✅ Project coverage is 29.75%. Comparing base (16b3f27) to head (38055ba).
⚠️ Report is 41 commits behind head on trunk.

Files with missing lines	Patch %	Lines
includes/Abilities/Utilities/Posts.php	0.00%	214 Missing ⚠️
includes/helpers.php	0.00%	26 Missing ⚠️
includes/bootstrap.php	0.00%	3 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##              trunk      #86       +/-   ##
=============================================
- Coverage     39.76%   29.75%   -10.01%     
- Complexity      107      136       +29     
=============================================
  Files            12       14        +2     
  Lines           591      830      +239     
=============================================
+ Hits            235      247       +12     
- Misses          356      583      +227     

Flag	Coverage Δ
unit	29.75% <0.40%> (-10.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JasonTheAdams]

HI @dkotter! This is a partial review. I'm curious why you decided to have a bunch of small abilities as opposed to a single get-post-details ability (the terms ability would still be separate)?

Also, let's add the meta parameter so this available via MCP.

[dkotter]

@JasonTheAdams

I'm curious why you decided to have a bunch of small abilities as opposed to a single get-post-details ability (the terms ability would still be separate)?

I went back and forth on this so happy to change this up (mentioned in the PR description):

I debated between registering a single new Ability (something like get_post_context) compared to registering Abilities for each individual piece of context. The former would be simpler but less flexible. Happy to go with that approach though if we think that's better.

Main thought was keeping these separate allow you to choose what details you want instead of just getting everything but also feels overcomplicated so I can change that to be a get-post-details Ability instead (maybe with optional filtering in the input schema so you can limit what is returned)

[dkotter]

@JasonTheAdams Modified things now to have two abilities: get-post-details and get-post-terms, let me know if that looks better.

Also, let's add the meta parameter so this available via MCP.

Can you point me to what parameter this needs? I'm not seeing anything in looking through the documentation for the Abilities API or MCP Adapter but likely just missing it

[JasonTheAdams]

Yeah, this is better, @dkotter!

Also, here's the doc on how to connect an Ability to MCP: https://github.com/WordPress/mcp-adapter/blob/trunk/docs/guides/creating-abilities.md

[dkotter]

Also, here's the doc on how to connect an Ability to MCP: https://github.com/WordPress/mcp-adapter/blob/trunk/docs/guides/creating-abilities.md

Ah, thanks for that. The main readme in that repo claims:

All WordPress abilities registered via wp_register_ability() are automatically available

So wasn't sure we needed to do anything else.

Added this in 78e35e0

[JasonTheAdams]

Great work, @dkotter! LGTM! 🎉