Short answer; no, I do not believe the number of developers is an input to an estimation activity. However, in constrast to the answer from @ChrisF, I also do not believe that developer skill, or any other facet of 'complexity' should be an input to an estimation activity.
See my (rather long) response to this question; Should you ever re-estimate user stories?, where I discuss my views on complexity and estimation.
Number of developers, developer skill, and other aspects of complexity (such as choice of language, existing code libraries available) are all factors which will contribute to how long a task takes, but they should not change the size of the task, which is what you should be aiming to measure in your estimations.
Another example (on top of the one in that other thread); you have a user story which reads something like; "I want a button, which when clicked will show an error message to unauthorised users". Now, your team estimates this task as "small" (at least, mine would!), and it goes in your backlog. Your team of 3 developers take 1 sprint to achieve this task. Another team of 10 developers may take 2 sprints to achieve the task, because this is their first ever job, and 7 of them don't share a common language. On the other hand, your lead developer by himself takes 1/2 a sprint to achieve this task, because he's done it before and knows some tricks.
At the end of these 3 different periods (1, 2, 1/2 sprints) what do you have? [thinking, thinking...] Correct! A button, which when pressed shows an error message to unauthorised users. The size of this task - has not changed between these 3 teams, they've all produced exactly the same output. However, other factors in the development process have affected the outcome in relation to time (and probably quality, code-reuse, and other nice things).
Estimating this way feeds much more effectively into velocity measurements (team 1 has good velocity, team 2 poor, and team 3 fantastic). Now we can adjust other aspects of the development process to get better results - e.g; give team 1 a couple more developers, split team 2 into smaller teams and add some experience, give team 3 some mentoring jobs so the other teams can improve.
On the other hand, if you estimate on complexity, or team capability, you skew your velocity, and conceal where the problems lie. Imagine instead that team 1 estimated the task as "medium", team 2 as "large" and team 3 as "small". We assign those estimates a velocity score of 10, 20, 5 respectively (for example).
Now after 1 sprint, team 1 has achieved 10 points, team 2 has 0 points (as the task is incomplete - but they will get 20 points after 2 sprints), and team 3 has 5 points (and probably another 5 as he could fit another small task into his sprint). AS you can see from these contrived example, the velocity of all teams is going to come out much the same. We have no way to then improve velocities. If you estimate this way, all you have come out with is an abstracted estimation of time.
To complicate this approach further - what seems complex now may not be so later (after you write more framework code, developers upskill, etc), or it may become more so (framework code is hard to work with, experienced developers leave the team, etc). So you'll need to re-estimate tasks every sprint to maintain consistency, which will mean re-estimating ALL (or many) tasks in your backlog so you can effectively prioritise them, which is all just wasted time - at the end of the activity, all teams are still producing the same button with the same warning.
So in summary, complexity, developer skill, team size, etc, should all form part of a planning activity, not a sizing activity. That way, it is clear that if you want the team to achieve more, you can adjust team metrics. You can not adjust time.
My response to a comment below is a bit long, so here it is in update form.
In regards to the "button" story; I just came up with some arbitrary story which could represent a single piece of work to illustrate my points. Another team might view this as a bigger task.
Estimating size of stories to a large extent depends on the Product Owner and the context of the system being developed (back-end, embedded, GUI, web, etc). I would aim to estimate the size in terms of what is being delivered, not how, or when. In the case of my example, the deliverable is a button and a dialog - 'small' size estiamtes to me. You could equally consider a deliverable to be a security framework, if that in itself is a deliverable for which the PO gains some perceived value (e.g; "I want single sign on support for our website so I don't have to remember lots of passwords").